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ABSTRACT 


This dissertation expands the current method of development and validation of 
conceptual models (CoM) of non-observable systems (NOSs) by using systems 
engineering (SE) and systems architecture (SA) methods during the model development 
process (MDP). A MDP is used to ensure that the models are validated and represent the 
real world as accurately as possible. There are several varieties of MDPs presented in 
literature, but all share the importance of the CoM. The improved conceptual model 
methodology (ICoMM) is developed in support of improving the structure of the CoM 
for both face and traces validation. The utility of ICoMM is demonstrated through the 
building of functional, physical, and allocated architecture products that improve the 
structure of the CoM for traces validation. ICoMM also incorporates a value model to 
ensure subject matter experts’ (SMBs’) values are documented early in the MDP for face 
validation. A well-constructed CoM supports model exploration of NOS when 
operational validation is not feasible. This dissertation uses a humanitarian 
assistance/disaster relief (HA/DR) scenario to demonstrate ICoMM’s ability to ensure 
documentation of SMEs’ values and that the structure of the COM links SMEs’ values to 
the fundamental objective. 
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EXECUTIVE SUMMARY 


This dissertation focuses on the importance of validation of conceptual models 
(CoMs) early in the model development process (MDP) by improving the structure of 
CoMs. A validated CoM early in the MDP also supports the operational validation of a 
classification of systems known as non-observable systems (NOSs). It presents the use of 
systems engineering (SE) and systems architecting (SA) methods to improve design and 
structure of the CoM to help decision makers (DMs) rely on the validation process to 
gain trust in the model. 

Conceptual models are built to provide a visual depiction of an idea of a system 
that addresses deficiencies in the real world. Several works pertaining to the development 
of models state the importance of the CoMs. However, literature is lacking on how to 
build the CoMs that facilitate conceptual validation and support operational validation of 
NOS. 

This research presents an improved conceptual model methodology (ICoMM) that 
supports the building of validated conceptual models with an improved structure and 
involvement of SMEs early in the MDP. Figure 1 presents Sargent’s evolved MDP. The 
ICoMM is implemented within Sargent’s evolved MDP to improve the structure of the 
CoM (Sargent 2001, 109). This research uses Sargent’s evolved MDP to examine the 
development of models (Sargent 2001). Sargent’s evolved MDP identifies two worlds, 
real and simulation. The real world is where deficiencies and requirements for systems 
are identified. The ideas of systems that have the potential to address the deficiencies are 
identified in “systems theories’’ (Sargent 2001, 109). Systems theories provide the bridge 
between the real and simulation worlds. The simulation is where models are built and 
experiments are conducted. It begins with building of the CoM. The CoM is built based 
on the systems theories identified in the real world. This dissertation has identified a lack 
of methodology on building a well-structured CoM. 


XIX 



Figure 1. 


Sargent’s Evolved Model Development Process 
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Source: Sargent, Robert. 2001. “Some Approaehes and Paradigms for Verifying and 
Validating Simulations Models.” Proceedings of the 2001 Winter Simulation Conference, 
109. 


ICoMM provides three areas of improvement within Sargent’s evolved MDP 
depicted by white circles with numbers as seen in Figure 2. The first circle is the 
transition from systems theories to the CoM. Systems engineering and systems 
architecture processes are applied to design, decomposition, and construction of a CoM 
based on the operational concept of the system developed in the real world. The 
improved structure identifies the measurement at the lowest level and links it to a single 
fundamental objective to facilitate trace validation. The second circle shows the improved 
structure of the CoM that emphasizes the greater incorporation of documenting SME 
values to facilitate face validation. The improved structure of the conceptual model 
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facilitates both top-down and bottom-up passing of information to support traces 
validation. The third circle is an improved definition of systems that are non-observable 
within the context of a MDP. This dissertation supplements the definition of NOS to also 
include future conceptual models, which the interaction between the conceptual system 
and an external system may not be observable. It demonstrates that a well-structured 
CoM supports the operational validation of a NOS with the inability to observe system 
behavior during execution of a simulation through model exploration of the CoM. 



Adapted from: Sargent, Robert. 2001. “Some Approaches and Paradigms for Verifying 
and Validating Simulations Models.” Proceedings of the 2001 Winter Simulation 
Conference, 109. 


The ICoMM is conducted in a sequence of four phases, each defined by activities 
and products that support the three areas of contribution mentioned earlier. Figure 3 
shows the visualization of ICoMM. ICoMM begins by using an operational concept to 
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create a system to address the identified need of the stakeholders. Next, a CoM is created 
using SE and SA to visually model the system and its components, as well as its 
interaction with the external system based on the operational concept. The CoM then 
goes through two validations processes, face and traces validations. Finally, operational 
validation of NOS is conducted using model exploration supported by the validated CoM. 


Figure 3. Improved Conceptual Model Methodology Visualization 
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ICoMM was applied to a Department of Defense (DOD) humanitarian 

assistance/disaster relief (HA/DR) mission scenario. ICoMM was compared to previous 

research using the same scenario. The result of this research revealed that applying SE 

and SA methods in model development improved the structure of the CoM. The new 

structure facilitated the traceability of multiple measurements of functions to a single 

fundamental objective, as opposed to the multiple objectives identified in previous 

research. It also identified the functions and components of the external system that 

affected the fundamental objective. ICoMM also established measures to hold SMEs 

accountable by documenting their values of the functions to be executed by the system 
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supporting face validation. Finally, using the ICoMM created a validated CoM prepared 
to conduct model exploration. This dissertation did not attempt to simulate the HA/DR 
mission. The scope of this research was to improve system definition and model structure 
from the previous research. 

The intent of ICoMM is to be used in multiple scenarios. It is applied when 
developing systems that are conceptual in nature to address needs in the real world. 
ICoMM improved the structure of the CoM to ensure traceability to a single fundamental 
objective and SMEs participation early in the MDP. If applied correctly, analysts can 
present DMs a well-structured model they can trust to make decisions that impact the 
entire organization. 
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I. 


INTRODUCTION 


The use of modeling and simulation (M&S) is an important aspect of the 
development of systems. An important aspect of M&S is the validation of the models to 
ensure that the models accurately represent the system in the real world. Validated 
models ensure that decision makers (DMs) are able to trust the results of the model to 
make decisions. This dissertation addresses the need for improvement of the validation 
methods of conceptual models (CoMs) to support operational validation of non¬ 
observable systems (NOSs). It presents the use of systems engineering (SE) and systems 
architecting (SA) methods to improve design and structure of the conceptual model that, 
in turn, will help DMs rely on the validation process to gain trust in the model. 

A system, defined by the International Council of Systems Engineering (INCOSE), 
is “a construct or collection of different elements that together produce results not obtained 
by the elements alone” (INCOSE 2015). Some systems are so large and complex that 
models of the system must be made to achieve better understanding of how the actual 
system will perform in the real world (Parnell, Driscoll, and Henderson 2011). Models are 
abstract representations of an actual system and are built before a system is fully produced 
or executed in the real world. Models are used to better understand aspects of the system 
that may not be identified in the real world (Sokolowksi and Banks 2009, 5). 

Several model development processes (MDPs) are presented in the literature as 
guides to building models that represent systems. The evolved MDP of Sargent (2001) is 
the primary example used in this dissertation. In his earlier work, Sargent (1984) 
introduces several concepts used for this research, such as CoM validation and NOSs, 
which are discussed in detail in Chapter II. 

As the models of systems go through the MDP, the models must be conceptually 
and operationally validated to ensure the model adequately reflects the user’s needs and 
gains the trust of DMs. The Department of Defense (DOD) (2008) defines validation as 
“the process of determining the degree to which a model, simulation, or federation of 
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model and simulations (M&S) and their associated data are accurate representation of the 
real world form the perspective of the intended use(s)” (3). 

Figure 1 displays the evolved Sargent’s MPD presented in 2010. The first phase 
of Sargent’s evolved MDP is to build the CoM. The CoM is a description of how the 
functions of the system will be executed to achieve the fundamental objectives defined by 
the DMs (Law 2007, 255). A detailed structured CoM provides traceability from 
performance measurements to the achievement of the fundamental objective. The 
traceability supports the validation of the CoM. 


Figure 1. Evolved Sargent’s Model Development Process 
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Source: Sargent, Robert. 2001. “Some Approaehes and Paradigms for Verifying and 
Validating Simulations Models.” Proceedings of the 2001 Winter Simulation Conference, 
109. 


2 





































Sargent (1984) presents two methods of CoM validation, face and traces 
validation techniques. Face validation, as Sargent describes it, involves subject matter 
experts (SMEs) with knowledge of the system, stating whether the design of the 
conceptual model is accurate and the input-output of the model is reasonable. Also 
known as a “peer assessment,” it is a subjective, yet effective method to evaluate models 
(Balci 1986). The other CoM validation method is traces validation. Traces validation 
follows the logic of the model to determine if the model is accurate and meets the need of 
the user (Sargent 1984). A validated CoM supported by the two validation methods 
contributes to the operational validation of the model performed later in the MDP. 

Operational validation of the model is to determine if the model’s output meets 
the intended purpose of the model. An important factor that affects the operational 
validation is whether the system is observable or non-observable (Sargent 1984). It is 
possible to collect data on the operational behavior for observable systems, while it is not 
possible for NOSs. Sargent (1984) uses two types of approaches for operational 
validation, subjective and objective, for both types of systems. There are two subjective 
approaches for operational validation of NOSs, exploration of model behavior and 
comparison to other models. The objective approach described by Sargent uses 
comparison to other models using statistical tests (Sargent 1984). An example of NOSs is 
future conceptual systems that are not in existence. The only operational validation 
method that can be used for future conceptual systems is the subjective approach of 
exploring model behavior (Sargent 2013). Future CoMs are systems that are not in 
existence and have no other systems or models of system to compare. Operational 
validation of the models of future conceptual systems is unfeasible if it is used in “what- 
if’ environments or is used to forecast system results (Balci 1986). The model output 
behavior(s) must be thoroughly explored to improve the confidence in the model of a 
NOS (Sargent 2013). 

This dissertation presents the idea that deviations from the intended outputs 
identified as a result of the simulation of a model of a NOS must be referred back to the 
CoM for model exploration. The structure of the CoM is reexamined to identify functions 
or objectives that may contribute to the deviation of the intended output. Based on the 
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updated information, DMs are able to make decisions quickly to adjust their course of 
action, identify new objectives, or give greater weight to different functions. It is assumed 
that if the simulation results of models of NOSs were as intended, the validated CoM 
would support operational validation and no further action would be needed. 

A. BACKGROUND 

Throughout history, people have used models to represent ideas, buildings, 
weapons, and even armies. Sokolowski and Banks (2009) use the game of chess, 
developed in the 15th century, to provide an example of M&S in history. The 
fundamental objective in chess is to obtain “checkmate,” by capturing the king. 

The chess pieces represent the components of the system, the chessboard is the 
simulated battlefield, and the execution of the game is the simulation (Sokolowski and 
Banks 2009). The game of chess can be seen as the origin of the modern-day war game. 
A set of rules outlines the functions of the pieces. The user determines the strategy used 
to execute the functions. Chess is a classic example of how DMs have used M&S to 
understand the system and the functions of components to achieve a fundamental 
objective. 

As time progressed, systems have become more complex. Modem buildings are 
taller, weapons are more lethal, and armies are bigger with capabilities beyond what was 
imagined when chess was developed in the 15th century. However, models are still used 
by engineers, scientists, and analysts to help gain better understanding of these complex 
systems. Models have also become complex to represent complex systems. 

Models are used to represent ideas either to improve an existing system or to 
introduce an entire new system to provide for a new need. These types of models are 
known as CoMs that are “theoretical representation of systems based on anecdotal or 
scientific observations” (Parnell, Driscoll, and Henderson 2011, 104). CoM development 
is the first task identified in several MDPs. The CoM provides the initial understanding of 
the purpose, assumptions, components, relationships, and interactions of the system. 
Diagrams and flow charts are used to create CoM. These drawings include a purpose, 
input variables, output variables, and controls of the CoM. The Integration Definition for 
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Function Modeling (IDEFO) language used in SE is a tool, which formally describes the 
system. The IDEFO is used by this dissertation and is further discussed in Chapter II. 

It is important that the DMs trust the CoM accurately represents the system to 
accept and use the model. The CoM must be validated to gain the confidence and trust in 
the model. Sargent defines CoM validation as “determining that the theories and 
assumptions underlying the conceptual model are consistent with those in the system 
theories and that the model representation of the system is ‘reasonable’ for the intended 
purpose of the simulation model’’ (Sargent 1984, 118). 

B. PREVIOUS RESEARCH 

Many articles have been published pertaining to the concept of CoMs and the 
validation of models. However, most refer to the definitions of CoMs and their validation 
presented by Robert Sargent. In 1979, Sargent wrote one of the earliest publications in 
the area of validation and presented a simplified model development process. The 
simplified process had three nodes that represented the system: problem entity, 
conceptual model, and computerized model. Between each of the nodes is either a 
validation or verification that was conducted to ensure the model in each node accurately 
represented the system as it progressed through the MDP. Sargent identified the CoM 
also as a “flowchart,’’ which led to the assumption that a flow chart was the primary 
method to represent the CoM. Sargent also presented various validation techniques to 
include face and traces validation. Sargent subsequently published articles on verification 
and validation (V&V) of models, introducing new concepts every few years. 
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Figure 2. Initial Version of Sargent’s Model Development Process 



Source: Sargent, Robert. 2001. “Some Approaches and Paradigms for Verifying and 
Validating Simulations Models.” Proceedings of the 2001 Winter Simulation Conference, 
108. 


In Sargent’s (1984) proceedings of the winter simulation conference, Sargent 
introduced the idea of CoM validation and the techniques used for validation. The CoM 
validation determines whether appropriate structure, logic, and relationships are 
identified. In this article, Sargent specifically identifies face and traces validation 
techniques to be used to validate CoMs. He also states that operational validation is 
affected by whether or not the operational behavior of the system is observable. A system 
is classified as observable if it is possible to collect data on the operational behavior 
(Sargent 1984). Sargent uses two types of approaches for operational validation, 
subjective and objective, for both types of systems. There are two subjective approaches 
for operational validation of NOSs, exploration of model behavior and comparison to 
other models. The objective approach only uses comparison to other models using 
statistical tests. Sargent does not discuss observable systems and NOSs in this article. 
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In 1986, in Balci’s proceedings of the Winter Simulation Conference, Balci 
introduced a MDP similar to Sargent’s MDP. Balci’s MDP had several additional steps 
compared to Sargent’s. However, the idea of developing the CoM and validating the 
overall model remains the same as Sargent’s model. The idea of using SMEs for model 
validation was also re i n f orced by Balci. He stated that peer assessment is an effective 
method for evaluating the acceptability of the model results (Balci 1986). Peer assessment 
consists of a panel of experts who evaluates the system based on their knowledge of the 
system. Balci (1986) also introduced the idea that SMEs identify indicators, an indirect 
measure of concepts: “The indicators are weighted and measured with an overall score’’ 
(40). However, validation may be unfeasible if the model is applied as a forecasting model 
to answer the “what if’ questions of a system model (Balci 1986). 

In 2001, Sargent improved the MDP, first presented in 1984. His evolved MDP is 
divided into two worlds, the real and simulation. The real world is where the system 
resides and the models of the system are in the simulation world. Sargent increases the 
number of phases to five in the simulation world in the evolved MDP from the previous 
three phases. The evolved MDP has the system theories reside in both the real and the 
simulation world to serve as a conduit between the two worlds. The four remaining 
phases in the simulation world are the CoM, simulation model specification, simulation 
model, and the simulation model data/results (Sargent 2001). The CoM is the logical 
representation of the system. The simulation model specification is the detailed software 
program written to implement the CoM in the simulation. The program must be verified 
to ensure the programming code is appropriate for the particular computer used for 
simulation. The simulation is the execution of the CoM in the computer. Finally, the 
simulation model data and results are the outputs of the simulation (Sargent 2001). 
Sargent adds that high degree of confidence is difficult to obtain for NOSs. Thus, he finds 
that model exploration of the behavior output should be explored and compared to other 
validated models if possible. 

In 2014, Andrew Turner conducted research on developing models for the 
simulation of NOSs. Turner’s research is the first attempt to develop a method to model 
NOSs. Turner uses Balci’s 1986 MDP to support his methodology. However, Turner 

7 



(2014) identifies the primary shortcomings of his methodology as linking the steps of the 
MDP and correctly identifying the structure of the system impacts on decomposition. 
Turner (2014), in his future works section, states that “continued research would 
investigate a process to enable a better transition from system definition to impact 
variable decomposition” (330). The structure presented by Turner does not link the 
measurements from the lowest levels in his structure and does not lead to a single 
fundamental objective. 

C. GAP 

Research into improving CoMs provides insights into the challenges faced by 
analysts to create models for simulation that can be trusted by DMs, especially if the 
systems are non-observable. The research gap identified by this dissertation is the lack of 
a method to build well-structured CoMs. This dissertation presents the idea that a well- 
structured conceptual model supports both conceptual and operational validations. 
Currently, there is a lack of research into the design of the CoM to support validation 
with SME involvement and a logical structure. A validated CoM also supports 
operational validation of NOS. An operational validation is unfeasible when the behavior 
of a model of a system is non-observable during the execution of a simulation. The only 
way to make sense of the simulation results is to conduct model exploration (Sargent 
2007). There are no current methods of exploring models of NOS. The CoM is the only 
model available for model exploration of NOS. This dissertation emphasizes the idea that 
an improved structure of the CoM provides increased traceability and greater 
accountability of SMEs. 

Turner’s work on modeling of NOSs for simulations is significant because it is 
unique. All other references to NOSs in the body of literature have been to define the 
term and the concepts. It does not demonstrate how to build the models or validate them 
for system use in the real world. Turner uses the limited information within the body of 
knowledge to present a method of modeling NOSs. 

Finally, Turner identifies two areas of continued work in the field of modeling of 
NOSs for simulation at the end of his research. It is in these areas where further 
contributions to the body of knowledge are made: 
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• Better transition from system definition to impact variable decomposition. 

• Proper development of structure for decomposition (Turner 2014, 330). 

Again, SE methods are used in this research to continue the previous work to 
improve the method of validation of models of NOSs so they are traceable and support 
current SME validation methods. 

Current research does not present methods to document SMEs values for face 
validation. Sargent notes that faces validation involves SMEs, but does not present how 
to involve SMEs in the development of models. There is also a lack of literature of how 
to conduct model exploration should the output of the simulation deviate from the 
intended output. 

The following research questions arise as a result of these identified gaps: 

• Is there a formal method of building a CoM of a system? If not, what are 
the methods available to build a CoM system? 

• What improvements can be made to the structure of the CoM to improve 
traceability of the model for validation? 

• How can SMEs values be documented to support CoM development and 
accountability during face validation? 

• Does model exploration of the CoM of a NOS support operational 
validation? 

• Can improving the CoM by using SE and SA methods support conceptual 
and operational validation when applied to a study of DOD organizational 
system during a humanitarian assistance/disaster relief operation 
(HA/DR)? 

D. CONTRIBUTION 

The primary contribution of this dissertation is the M&S domain. Figure 3 shows 
the areas of contribution as noted by the three white circles and the corresponding numbers. 
This dissertation presents a methodology that improves of the structure of the CoM for 
validation from previous research. The first circle is the transition from systems theories to 
the CoM. Systems engineering and systems architecture processes are applied to design, 
decompose, and construct a CoM based on the operational concept of the system developed 
in the real world. The improved structure identifies the measurement at the lowest level and 
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links them to a single fundamental objective to facilitate trace validation. The second circle 
shows the improved structure of the CoM that emphasizes the greater incorporation of 
documenting SME values to facilitate face validation. The improved structure of the 
conceptual model facilitates both top-down and bottom-up passing of inf ormation to 
support traces validation. The third circle is an improved definition of systems that are non¬ 
observable within the context of a MDP. It adds to the definition that, for future conceptual 
models, the interaction between the conceptual system and an external system may not be 
observable. This dissertation demonstrates that a well-structured CoM supports the 
operational validation of a NOS with the inability to observe system behavior during 
simulation execution through model exploration of the CoM. 



Adopted from: Sargent, Robert. 2001. “Some Approaches and Paradigms for Verifying 
and Validating Simulations Models.” Proceedings of the 2001 Winter Simulation 
Conference, 109. 
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E. RESEARCH APPROACH 


This dissertation presents a methodology to present DMs with a visual CoM. The 
idea of building a CoM is taken a step further by establishing a methodology based on SE 
and SA concepts and assert that the methodology improves CoM validation. This 
research acknowledges that the methodology presents only a small improvement on the 
foundation of the idea of CoMs and its validation. However, it does address specific areas 
of improvement identified by previous research, systems definition, and structure. Future 
works section points to the areas that should be examined as further research in this area. 

The result of the research is the formalization of an Improved Conceptual Model 
Methodology (ICoMM). ICoMM was used to build a CoM of the HA/DR mission used 
by a previous research to demonstrate the improved method of defining the system and 
structure of the model. 

F. DISSERTATION ORGANIZATION 

Chapter If reviews model development processes and validation methods. System 
engineering and systems architecture are also reviewed. It covers systems design and 
architecting techniques to decompose a system to understand its requirements, the 
functions and the components, and how it interacts with an external system. The 
definition of NOS is explored to gain an understanding of the challenges of modeling 
NOS and its operational validation. 

Chapter III presents the improved conceptual model methodology (ICoMM). 
ICoMM uses SE and SA processes to improve the structure of the CoM that facilitates 
validation. 

Chapter IV demonstrates the utility of this research by exploring the conceptual 
modeling of NOSs. A humanitarian assistance/disaster relief (HA/DR) scenario used in 
previous research is explored in this research to improve the design of the interaction 
between the system and the external system. SE and architecting principles are applied to 
show improved traceability from the measurements of performance and effectiveness to 
the fundamental objective. 
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Chapter V concludes the dissertation with a summary of the research and 
contributions. Recommendations for extensions of this research are included in the future 
works section. 
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II. LITERATURE REVIEW 


The focus of this dissertation is improving the CoM by establishing a structure 
that supports face and traces validation of the CoM. It also investigates the operational 
validation of NOSs. This dissertation presents the integration of SE and SA methods to 
improve the structure of COMs. Face validation is also enhanced by inclusion of SMEs’ 
values early in the MDP. 

It is important to establish a baseline of understanding of models and how models 
help to gain insights of systems. First, this chapter reviews the definition of models and 
its uses. Next, a review of several MDPs is presented with an emphasis on Sargent’s 
(2001) evolved MDP. Sargent’s evolved method for model development is the foundation 
of this dissertation. According to Sargent (1984), there are two main model validation 
phases of the MDP, the CoM validation, and the operational validation. SE and SA 
methodologies are review to understand how a system is decomposed to identify its 
functions and components. The decomposition of the systems helps to improve the 
structure of the CoM and its validation. Operational validation is conducted based on the 
results of a simulation (Sargent 2010). For NOS, operational validation is difficult due to 
its complexity. 

Many categories of systems already exist in the SE domain. Blanchard and 
Fabrycky (2006) describe a few of the classifications of systems, such as natural and 
human-made, physical and conceptual, static and dynamic, closed and open systems. This 
chapter reviews the classification of systems known as observable systems and NOSs to 
identify the differences and how both are operationally validated. The term NOS is a 
difficult concept to understand and not used very often in the M&S domain. 

Very little is written on the subject of NOSs within the M&S domain. To gain an 
understanding of modeling NOS, it is important to establish a foundation of 
understanding of the definition, engineering, design, and architecture of systems. Parnell, 
Driscoll, and Henderson (2011) acknowledge that analysts must consider the 
interdisciplinary systems thinking approach to model systems. The MDP and the 
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validation techniques are discussed to present SE integration into a MDP. This chapter 
also establishes how a validated COM supports the operational validation of NOS. 

A. MODELS 

Models are important tools in today’s society. People depend on models in 
everyday life, from the engineer who tries to improve the structure of an airplane to 
architect who strives to build a more efficient home. In similar ways, models help DMs 
gain information about systems to make decisions. Thus, a model is defined as “an 
abstract representation of a system’’ (Parnell, Driscoll, and Henderson 2011, 99). 

1. Model Development Processes 

It is imperative that all models go through a MDP. A MDP can be as informal as a 
simple drawing on a napkin or as formal as a methodology presented in an engineering 
class. In 1979, Robert Sargent presented his simplified version of the MDP during the 
Winter Simulation Conference. Since then, many others have presented different MDPs. 
However, Sargent’s MDP has been the main source cited by many in the model 
development community and THER DOD. There have been several updates to Sargent’s 
1979 MDP; however, the basic concepts of model development remain relevant. 

a. Early Sargent’s Model Development Processes 

Sargent used his simplified modeling process model to explain the verification 
and validation steps necessary during the modeling process. This dissertation refers to 
this process as the “Sargent circle,’’ as it was used in Turner’s (2014) dissertation. 

The circle in Figure 4 has three main components: the problem entity, the 
conceptual model, and the computerized model. The first component is the problem 
entity. Sargent (2007) calls this component the “system’’ in future updates of his paper. 
He describes the system as “real, proposed, idea, situation, policy, or phenomena to be 
modeled’’ (Sargent 2007, 126). The next component of the circle is the development of 
the conceptual model. It is the model developed based on the inputs from the 
stakeholders of their understanding of the system. The final component of the circle is the 
computerized model. The computerized model is programmed based on the CoM to run a 
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simulation on a computer (Sargent 1984). There are V&V aspects between each of the 
components. V&V is discussed in further detail later in the chapter. 


Figure 4. The Original Sargent Circle 



Source: Sargent, Robert. 1984. “A Tutorial on Verification and Validation of Simulations 
Models.” Proceedings of the 1984 Winter Simulation Conference, 116. 


b. Evolved Sargent*s Model Development Processes 

Sargent (2001) updated his simplified modeling process and presented it to the 
American Society of Mechanical Engineers. The updated model is referred as the 
“Evolved Sargent’s Circle’’ (Turner 2014, 32). The term “Evolved Sargent’s MDP’’ is 
used in this dissertation to demonstrate the application of the Evolved Sargent’s Circle as 
a MDP. Figure 5 is an example of the Evolved Sargent MDP presented during the 2001 
Winter Simulation Conference. The updated model depicts two worlds, the real world 
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and the simulation world. The real world shows a system subjected to experimentation. 
The analysts have hypothesized and abstracted ideas of the system based on system the 
system need and expected results to address the need. The design process of creating the 
functional, physical and allocated architecture decomposes the system based the system 
theories from the real world. These ideas are then turned into theories regarding the 
performance and the expected effects the system will produce. The system enters the 
simulation world with the established theories to begin construction of the COM. The 
completed COM is then validated to ensure it reasonably matches the systems theories 
(Sargent 2010). 

The next component of the evolved MDP is the simulation model specification. 
The products of the CoM are the objectives for the simulation (Sargent 2010). This is the 
description of the software design and where the specification of the simulation model is 
verified. The simulation is executed once the specifications have been verified. The 
simulation is the execution of the CoM developed earlier based on system theories. The 
results of the simulation are the basis for validation of the model of the system. The 
evolved circle is much more detailed but the general ideas are the same. 


16 



Figure 5. Real World and Simulation World Relationship with Verification 

and Validation 
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Source: Sargent, Robert. 2001. “Some Approaehes and Paradigms for Verifying and 
Validating Simulations Models.” Proceedings of the 2001 Winter Simulation Conference, 
109. 


2. Conceptual Models 

Sargent states that a CoM is “the mathematical/logical/verbal representation of the 
problem entity (system)” (Sargent 2010, 169). The CoM is the first model to be built in a 
MDP. It is built early in the MDP to identify and correct any deficiencies before using 
more resources throughout the development process. This research has not found a 
structured methodology on building a CoM. There also is a lack of understanding of how 
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to achieve a “good” CoM. Teeuw and van den Berg (1997) presented general criteria for 
development of CoMs quoted here: 

• Completeness: The concepts must be expressive enough to capture all 
“essential aspects” of the real world. 

• Inherence (propriety): The concepts should be straight to the point and 
focus on essential aspects only. 

• Clarity: A designer must be able to comprehend the concepts and rules, as 
well as be able to apply them in models without spending too much time 
and effort (subjective) 

B. VERIFICATION AND VALIDATION 

1. Verification 

As discussed previously, models are a representation of the system. To ensure that 
the models are credible representation of the system, they must be verified and validated. 
A credible model will assist in answering whether the results of the models are accurate 
depictions of the system. A validated model is also important because the information 
gained from the model is used by DMs to make decisions. DMs must have the confidence 
that the results of the model are correct to make decisions that affects the entire 
organization. 

The DOD Standard Practice Document MIL-STD-3022 (2008) defines 
verification as, “The process of determining that a model, simulation, or federation of 
models and simulations implementations and their associated data accurately represents 
the developer’s conceptual description and specifications” (10). In the computer science 
(CS) domain, it “is ensuring that the computer program of the computerized model and 
its implementation is correcf’ (Sargent 2010, 166). Verification of the model is generally 
understood, as the focus was on ensuring that the model was built correctly. The CS 
interpretation is used to ensure that there are no bugs in the program and each line of 
code executes as intended. Verification is an important way to ensure that each of the 
system components performed as expected during the tracing of effects to the objectives 
of the NOS. 
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2 . 


Validation 


Non-observable systems present unique challenges to the validation process. The 
MIL-STD-3022 defines validation as 

the process of determining the degree to which a model, simulation, or 
federation of models and simulations, and their associated data are 
accurate representations of the real world from the perspective of the 
intended use(s) (Department of Defense 2008, 2). 

Validation answers the question of the accuracy of the model (Sokolowski and 
Banks 2009). Numerous validation techniques are well documented in literature. Over 77 
V&V techniques can be applied for two major stages in the modeling process (Balci 
1986). Sargent (2013) lists 15 validation techniques in his most recent paper. Sokolowski 
and Banks (2009) list 11 in their modeling and simulation books. All those validation 
techniques can be grouped into two major types of validation: subjective and objective. 
Objective validation is the use of mathematics or statistics to validate the model. 
Subjective validation is relying on non-numerical methods to validate the model, such as 
face and trace validation techniques. Many times, a combination of objective and 
subjective validation techniques are used. 

Sargent (2010) states that a model is considered valid if the model’s accuracy is 
within an acceptable range established by the stakeholders. The model’s accuracy is 
measured by its results; thus, it is important to identify the variables early in the 
development process. As we revisit the Evolved Sargent Circle, validation occurs early 
on with CoM validation and ends with operational validation. 

CoM validation is the demonstration that the conceptual ideas that are the bases for 
the CoM are accurate representations of the real world theories of the system and the models 
representing the system “are reasonable for the purpose of the model” (Sargent 2010, 173). 
Many times the face validation technique is an appropriate choice for CoM validation. Face 
validation is using SMEs or individuals who have knowledge about the system to address 
whether the model adequately represents the system in the real world. The SMEs normally 
require the use of flowcharts or graphical models (Sargent 1986), or a set of model equations. 
This technique is known as traces. Traces validation is tracking the system through each of 
the components to the overall model to determine if the model is correct. 
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Appleget, Blais, and Jaye (2013) present the importance of the development of the 
COM to “provide the developer’s interpretation of what is needed to achieve the user’s 
objectives” (Appleget, Blais and Jaye 2013, 5). They state that three essential items are 
needed for a model to be validated: the CoM, a referent, and the description of the data. 
The CoM is previously defined. The referent is the laws or science theories that will be 
used to model the system. The description of the data is needed to ensure that the model 
has the required collection of data. These three items are known as the “validation 
triangle” and are part of another model development process. Figure 6 depicts how the 
validation triangle fits into the overall model development process. 


Figure 6. Validation Triangle 
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Source: Appleget, Jeffrey, and Blais, Curtis, and Jaye, Mietiael. 2013. “Best Praetiees for 
US Department of Defense Model Validation: Lessons Learned from Irregular Warfare 
Models.” Journal of Defense Modeling and Simulation: Applications, Methodology, 
Technology, 3. 
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An operational validation is conducted to determine if the results of the model 
sufficiently represent the results of the actual system and its applications. If the model is 
determined not to represent the system sufficiently, analysts must be able to retrace the 
model’s behavior to identify what caused the deviation. Analysts can use analytical 
methods to identify the cause to find the deviation and objectively validate the model. If 
analytical methods are not possible, subjective methods can be used to validate the 
model. 

C. SYSTEM 

A system is understood as an integrated set of elements that accomplish defined 
common objectives (Parnell, Driscoll, and Henderson 2011). A system can consist of a 
wide-ranging set of elements, such as people, organization, facilities, procedures, 
collection of hardware and software (Buede 2009). Parnell, Driscoll and Henderson 
(2011) outline key attributes of a system as the following quoted here: 

• Have interconnected and interacting elements that perform systems 
functions to meet the needs of consumers for products and services. 

• Have objectives achieved by system functions. 

• Interact with their environment; thereby, creating effects on stakeholders. 

• Require systems thinking that uses SE throughout process. 

• Use technology developed by engineers from all engineering disciplines. 

• Have a systems life cycle containing elements of risk that are (a) identified 
and assessed by systems engineers, and (b) managed throughout this life 
cycle by engineering managers. 

• Require systems decisions, analysis by systems engineers, and decisions 
made by managers (3). 

It is important to understand that the elements of an organization are 

interconnected and interact with each other to support the organizational system. The 

organization provides services to achieve defined objectives executed by its functions. By 

providing services, the organization must interact with the environment. This interaction 

creates effects that the stakeholders must understand to make future decisions about the 

organization and its processes. Thus, analysts use the systems thinking approach to 
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identify the critical system structure that will affect its interaction with the environment. 
New technology from a wide-ranging engineering discipline may be introduced to assist 
with the interaction or the decision-making process. A system life cycle process will be 
used to guide the system from conception to retirement and ensures that the objectives of 
the system are met throughout the entire life of the system. Using the attribute list as a 
guide, it is possible to begin the SE process. 

D. OBSERVABLE AND NON-OBSERVABLE SYSTEMS 

The determination of which objective or subjective validation techniques is 
necessary depends on whether the system is observable or non-observable. Robert 
Kalman (1959) originally defined for dynamic systems as “If a*j is not an observable 
costate, then the state Xi cannot be determined; in other words the plant’s (system’s) 
behavior cannot be i n f erred from the measurements’’ (486). Dahleh, Dahleh and 
Verghese (2011) further described an observable system as, “The initial state x(0) can be 
uniquely determined from the input and output measurements if the system is 
observable.’’ Figure 7 graphically shows the determination of observable systems and 
NOSs as defined in the domain of control theory. Thought bubbles are added to compare 
each component of the figure to the M&S domain. Figure 7 presents a system with an 
unknown initial state. The inputs of the system are executed and outputs are produced. If 
the initial state of the system can be determined, then the system is classified as 
observable. It is classified as non-observable if a determination cannot be made. 
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Figure 7. Overview of Observable and Non-Observable Classification 



1. Observable Systems 

Sargent (2010) defines observable system, “as it is possible to collect data on the 
operational behavior of the problem entity during the execution of a simulation” (174). 
For observable systems, analysts are able to observe the behavior of the system during 
the operation of the model and evaluate the system throughout its execution. A physics- 
based model, such as a small unit force on force lethal engagement, can use laws of 
physics as its referent to forecast the behavior of the system and there is very little to no 
deviation from the expected effects to actual effects. If there are deviations, analysts can 
refer back to the original equations to identify any deficiencies. In such cases, the referent 
is implicit. The referent comes from the laws that have been used to represent past 
combat (Appleget, Blais, and Jaye 2012). 

2. Non-Observable Systems 

A NOS is the opposite of the observable system where it is not possible to collect 
data on the operational behavior of the problem entity. It is difficult to assess the quality 
of the model because there is not enough information about the system to understand its 
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behavior fully. This is especially true for models of systems that are nonexistent or in 
development for future operations. The quality assurance of the model is still a challenge 
even for existing systems that are not completely observable (Balci 1986). 

The definition of a NOS in the M&S domain is not clear. Turner (2014) described 
NOSs as systems that do not facilitate the collection of data. In order to provide an 
example, Turner (2014) uses an anti-piracy operation scenario as an example of 
simulating a NOS. He identifies in the scenario that there is sufficient knowledge of the 
units conducting the operation. The uncertainty of the behavior of the pirates is too great 
to build a model to examine the results of the interaction (Turner 2014). Thus, there is a 
need for a non-traditional approach to modeling a NOS to overcome the uncertainty. 

A future conceptual system can be classified as a NOS due to the lack of 
information about its components. It can be a current system where the interactions 
between the components are not observable. Examples provided in the most recent 
literature about a NOS are of non-physics-based systems interactions with external 
systems. 

3. Validation of Observable and Non-Observable Systems 

Sargent (2007) suggests that a NOS can be operationally validated using two 
different approaches, subjective or objective. Table 1 outlines Sargent’s approaches to 
operational validity for NOSs. The objective approach cannot be used because for future 
conceptual systems, there are no other models to compare. In addition, with no data, 
statistical tests are meaningless. Even in the subjective approach, there would be no 
comparison to other models. Thus, the only method of operational validity of a NOS is 
through model exploration. 


24 



Table 1. Operational Validity Classification for Non-Observable Systems 


Non-Observable System 

Subjective 

Approach 

• Explore Model Behavior 

• Comparison to Other Models 

Objective 

Approach 

• Comparison to other Models 

Using Statistical Tests 


Sargent, Robert. 2007. “Verifieation and Validation of Simulation Models.” Proceedings 
of the 2007 Winter Simulation Conference: 130. 


An observable system also uses objective validation techniques for validation. An 
operational validation for an observable system is achieved when the outputs match the 
expected output that supports the fundamental objective. For a NOS, the outputs do not 
match the expected outputs. Therefore, in a NOS, the COM is evaluated to conduct 
model exploration. 

The model of the system is determined to be a failure after multiple iterations of 
the simulation and never meets the expected output. The model may never converge to 
determine the initial state of the system due to not knowing which function prevents 
outputs from matching the expected output. Buede (2009) describes the failure of a 
system is determined when the process is also not observed and the system does not 
maintain a copy of its requirements. A point of fault cannot be determined and a new 
system must be created to address the deficiencies. 

E. SYSTEMS ENGINEERING 

Buede (2009) defines systems engineering as “engineering discipline that 
develops, matches, and trades off requirements, functions, and alternate system resources 
to achieve a cost-effective, life-cycle-balanced product based upon the needs of the 
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stakeholders” (10). There are eight functions listed by Buede (2009) quoted here as an 
overview of the complete SE process: 

Oa Define the problem to be solved 

Ob Define and evaluate alternate concepts for solving problem 

1. Define the system-level design problem being solved 

2. Develop the system functional architecture 

3. Develop the system physical architecture 

4. Develop the system allocated architecture 

5. Develop the interface architecture 

6. Define the qualification system for the system (51). 

This research uses the last six functions to investigate the concept of non¬ 
observable systems and to build its architecture. 

1. Systems Engineering Process 

A system simply does not appear, as it goes through a methodical SE process to 
ensure that the system works and meet the stakeholders’ needs. A very important aspect 
of SE is its relationship to the system life cycle. There are many examples of systems life 
cycle models in literature, but the most common aspects are conceptual design, 
development, production, training, operations and maintenance, refinement, and 
retirement. 

SE is multidisciplinary in the fact that it involves the integration of knowledge 
and best practices from different disciplines into the development and an interconnected 
and interrelated system. The engineering of integrating these components and ensuring 
that the system meets the needs of the stakeholders is what makes SE unique from other 
engineering disciplines. 

INCOSE notes that the SE process has an iterative nature that supports learning 
and continuous improvement (SE Handbook Working Group 2011). It is during the 
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engineering process that the analysts gain a better understanding of the stakeholders’ 
needs and apply this knowledge to the design and the functionality of the system. The 
analyst may discover unexpected or emergent properties as the system performs its 
functions and interacts with its elements, external systems, and environment. This can be 
attributed to the complexity of the system. By using the SE process, analysts are able to 
develop the design and integrate the components to create an effective system that 
enables the public to trust the banking system and continue to deposit their money at their 
local banks. 

One of the standards that analysts use is the military standard 499B (1993), as it 
defines the engineering of systems as “an interdisciplinary approach encompassing the 
entire effort to evolve and verify an integrated and life cycle balanced set of system 
people, product, and process solutions that satisfy customer needs” (Department of 
Defense 1993, 40). In the technical draft, quoted below, it states that SE encompasses the 
following: 

• Technical efforts related to the development, manufacturing, verification, 
deployment, operations, support, disposal of, and user training for system 
products and processes 

• The definition and management of the system configuration 

• The translation of the system definition into work breakdown structures 

• The development of information for management decision (Department of 
Defense 1993, 40) 

The SE process has key concepts that must be reviewed to design a NOS. Each 
concept is a building block for designing overall systems architecture of a NOS. 

Buede (2009) defines operational concept as a “vision for what the system is (in 
general terms), a statement of mission requirements, and a description of how the system 
will be used” (481). The operational concept provides an overall view of how the system 
will interact with the external system. A military example of an operational concept 
would be the purpose of a military mission and how it will interact with the enemy or 
local populous. An external systems diagram establishes the boundaries of the system and 
the external systems with which it may interact. Objectives hierarchy is the hierarchical 
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list of objectives that must be met. The hierarchy is based on the requirements and values 
of the stakeholders. Requirements are defined as the tasks that must be completed to meet 
the stakeholders’ needs. Functions are the action that the system performs to produce the 
intended effects, and they serve as the foundations of building a functional architecture, 
which is discussed in more detail later in this chapter. Items are the inputs that go into the 
system. Components are the physical aspect of the system. It is the physical items that 
perform the functions. Interfaces are where components and systems are connected. It is 
the location where components and systems interact with each other. It is in these spots 
where observations may not happen during initial testing of a system. 

2. The Vee Model 

There have been several different processes developed to assist with engineering a 
system. Figure 8 shows the “Vee” process, which describes SE as being composed of 
decomposition of a system followed by the integration to improve the system. The left 
side of the Vee is the decomposition of the system that presents three phases of 
understanding the requirements, developing the system performance specification and 
system validation plan, and expanding the performance specifications into a 
configuration item verification plan. Decomposition is the “hierarchical, functional and 
physical partitioning of any system into hardware assemblies, software components, and 
operator activities that can be scheduled, budgeted, and assigned to a responsible 
manager” (Forsberg, Moos, and Cotterman 2005, 110). The Vee model’s focus on 
decomposition and design is to improve the understanding of the operational needs and 
translate it to system-level requirements (Buede, 2009). Also, note that the decomposition 
is conducted from the overall system to subsystems to entity levels. It is through this 
decomposition that the system can be identified to its entities to correct errors and fill 
gaps. 
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Figure 8. The SE ‘‘Vee” Model 



Source: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: John 
Wiley & Sons, 10. 


The horizontal line shows where the analysts mentioned earlier take the 
requirements and produce the physical aspects of the system (Buede, 2009). The 
conceptual model of the system developed on the decomposition side of the Vee is the 
“blue print” the other analysts will follow to develop a physical system and begin its 
integration. As mentioned previously, the conceptual model must be created with limited 
errors and gaps filled to reduce the overall cost of creating the system. 

The right side of the Vee is the integration and verification of the system. This is 
where the system is put together from its entities to sub-systems to the overall system. 
The system is tested to ensure that all of the elements are in compliance and meet the 
stakeholders’ satisfaction. 
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3. 


The Waterfall Model 


The waterfall model developed by Dr. Winston W. Royce is another widely 
accepted SE model. As seen in Figure 9, the waterfall is a linear model that is very risk 
adverse (Forsberg, Mooz, and Cotterman 2005, 106). Unlike the Vee, the waterfall is 
easier to understand due to its simplicity. This simplicity makes the waterfall lacks some 
important aspects of SE, such as the integration of specialists to create the model of the 
physical system for integration, verification, and validation. The waterfall is a linear path 
from top to bottom from the system requirements phase to operations and maintenance. It 
leaves little opportunity to introduce new ideas during the development process. The 
waterfall does allow changes by conducting a backward iteration to change its baseline. 
Because the model emphasizes the flow down of progress, going backward is not cost 
effective and it is difficult to repeat steps. 


Figure 9. The Waterfall Model 



Source: Royce, Winston W. 1970. “Managing the Development of Large Software 
Systems.” Proceedings of IEEE WESCON, 329. 
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4. 


The Spiral Model 


The spiral model was created to improve on the developments of the waterfall 
model and to improve the process. The spiral, unlike the linear waterfall, as the name 
attests is non-linear and emphasizes repeatability during its development process. Figure 
10 shows the spiral model presented by Boehm (1988). In Boehm’s model, each spiral is 
in essence an iteration of the waterfall model (Parnell, Driscoll, and Henderson 2011). 
The spiral also introduces the concept of risk analysis throughout its cycle. The system 
must successfully mitigate identified risks at each phase to move on to the next phase. 
Failure to resolve any risks can lead to delays or even termination of the overall system. 



Source: Boehm, Berry W. 1988. “A Spiral Model of Software Development and 
Enhaneement.” Computer, 64. 
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The three SE process models all present different ways to develop a system. 
However, they all share the characteristics of identifying requirements, design, 
development, maintenance, and retirement. Although the analyst is involved in all the 
phases during the SE process, the design phase is where they are mostly involved. 

F. SYSTEMS DESIGN 

Buede (2009) describes system design as transforming stakeholders’ ideas of 
systems into visual models by engineers. Designing a system requires several steps. A 
system is decomposed, requirements identified, and the architectural representation of the 
system created (Buede 2009). Turner’s (2014) research identified that designing models 
of NOSs for simulation needed more research into the proper development of its 
structure. 

Blanchard and Fabrycky (2010) explain that the basis of establishing the structure 
of a system starts with the design of the system. The design is an analyst’s vision of how 
the system will meet the requirements identified by the stakeholders (Blanchard and 
Fabrycky 2010). The design of a system takes form as early as the initial interaction 
between the stakeholders and the analyst. The initial design is not the final design and the 
traceability of its effects to the objectives. 

Figure 11 illustrates the importance of ensuring a well-designed system early in 
the life cycle process. The X-axis represents the life cycle phases and the Y-axis 
represents the percent of the cost of developing the system. The programmed cost of the 
cost committed curve has a steady increase to 100% while the actual cost incurred 
displays a steep rise during the construction and production phase. At the end of the 
“detailed design and integration’’ phase, the cost committed is at 80% while the incurred 
cost is only 20%. Ensuring that the system’s functions, components, and interfaces are 
clearly defined and are traceable to the requirements outlined by the stakeholders is 
important to ensuring that costs, no matter how it is defined, are reduced for developing a 
system. 
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Figure 11. Systems Life Cycle versus Cost 



Source: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: John 
Wiley & Sons, 8. 


The systems cost curve is also in line with Sargent’s model of cost versus value as 
seen in Figure 12. As the confidence in the model increases, both the value and the cost 
also increase (Sargent 2010). However, examining the cost and value curves, the two 
curves intersect, which indicates the return on the cost is not worth the value of the 
model. Sargent (2010) states that the cost of the model may not justify the attempt for 
absolute validation of a model. Thus, improving the methods of existing validation 
methods are ways to ensure that the cost of the model meets the values of the 
stakeholders. 
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Figure 12. Confidence that Model Is Valid 


Cost 



Source: Sargent, Robert. 2007. “Verifieation and Validation of Simulation Models.” 
Proceedings of the 2007 Winter Simulation Conference, 125. 


A well-designed conceptual model will improve the structure to ensure that the 
effects of the system are traceable and support the validation of the NOS. Using the Vee 
model discussed earlier, the design phase is primarily focused on the left side or the 
decomposition side of the Vee model. Architecting is an important aspect of system 
design. Architecting techniques are used to decompose the system into functions, 
components, and allocation. The next section provides an in-depth review of architecting. 
The right side of the model describes the integration and the qualification of the system. 
During this phase, the model of the system goes through the verification and validation 
phase to ensure that the system design decomposed on the left side supports the defined 
requirements. 

G. SYSTEMS ARCHITECTING 

The term architecture has traditionally been related to physical buildings. It is the 
way people have been designing and constructing structures throughout history. Systems 
engineers have borrowed architecting concepts to solve the difficulties of designing 
complex systems (Maier and Rechtin 2000). Architecting is a way for analysts to 
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decompose the system to translate the needs of the stakeholders and the solutions of how 
the systems will satisfy the needs. During the design phase, or the left side of the Vee 
model, three types of architectures, the functional, physical, and allocated, are used for 
the decomposition process (Levi 1993). Figure 13 depicts Levi’s (1993) architecture 
development model as outlined by Buede. The architectural development process starts 
with the operational concept. Buede describes the operational concept as an overview of 
the system. The operational concept describes the mission, requirements, and the 
execution of the system. Functional, physical, and allocated architectures are developed 
as part of the decomposition of the system (Buede 2009). The functional architecture 
describes what the system will do. The physical architecture depicts what components are 
available in the system. The allocated architecture is the mapping of functions to 
components (Buede 2009). It is important that all three of these models are developed 
independently to identify the functions and the components that perform the functions to 
integrate the two architectures. 


Figure 13. Architecture Development in the Engineering of a System 



Source: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: John 
Wiley & Sons, 28. 
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Architecting is an important tool the analyst will use to decompose the NOS to 
allow traceability of the effects. The combination of the architectures helps to answer 
which component with which functions had the greatest impact on the results of the 
system. 


1. Functional Architecture 

The Merriam-Webster dictionary defines the term function, “as the special 
purpose or activity for which a thing exists or is used” (Merriam-Webster 2015). For our 
purposes, it is possible to substitute the word “thing” with system. It is what the system 
will perform at its basic definition. A more comprehensive definition provided by the 
INCOSE defines the term function as, “A characteristic task, action, or activity that must 
be performed to achieve a desired outcome” (INCOSE 2003, 281). Functions may be 
accomplished by one or more components of the “system comprised of equipment 
(hardware), software, firmware, facilities, personnel, and procedural data” (INCOSE 
2003, 123). Buede (2009) also defines the term function as, “a process that takes inputs in 
and transforms these inputs into outputs.” Combining INCOSE’s and Buede’s definitions 
provides a robust understanding of the term function. A function is when a system takes 
inputs in, which are tasks, actions, or activities, and the output should be the desired 
system behavior. However, when the output of the function deviates from the desired 
system behavior, an error or failure may occur. In the fault-tolerance community, an error 
is determined when the system is able to observe the changes of the system. Since an 
error is observed, it can be identified and corrected. However, an analyst normally is not 
able to monitor the entire state continuously, as not all errors are able to be observable, 
which leads to system failure. A failure in the system is an unobserved deviation from the 
system requirements. Figure 14 depicts a concept map for fault tolerance terms as 
described by Buede. 
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Figure 14. Concept Map for Fault Tolerance Terms 



Source: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: John 
Wiley & Sons, 243. 


A functional architecture enables the analyst to organize the many functions the 
system must perform, ft does this by decomposing the system’s top-level function and 
outlining what they system must do. ft is the functional architecture that allows the 
“hierarchical arrangement of functions, their internal and external functional interfaces, 
their respective functional and performance requirements, and the design constraints” 
(INCOSE 2004, 124). 

The functional architecture outlines the tasks of the system. One of the ways is 
with a model of a functional hierarchy showing the functions to be performed by the 
system and its components (Buede 2009). Another use of the functional architecture is 
capturing the transformation of the inputs, outputs, controls, and the mechanisms of the 
system. 

To build a functional architecture, an analyst must perform several steps. First, the 
analyst must define the system’s functions by conducting a functional analysis. A 
functional analysis is conducted to identify the required functions of the system and its 
internal and external interfaces, ft is one of the earliest processes to be performed in the 
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system life cycle. There are several methods to perform functional analysis. The output of 
all functional analysis is the identification of system functions and interfaces (Parnell 
Driscoll, and Henderson 2011). Parnell, Driscoll, and Henderson (2011) list four main 
functional analysis techniques: Functional hierarchy, functional flow diagram, IDEFO, 
and modeling and simulations. IDEFO and modeling and simulations are discussed in 
more detail later in the chapter. 

a. Functional Hierarchy 

A functional hierarch provides an understanding of the functions that the system 
must perform from top to bottom. It is the foundation of more detailed functional analysis 
conducted throughout the life cycle (Parnell Driscoll, and Henderson 2011). The 
functional hierarchy does not identify interrelationships between system components. 

b. Functional Flow Diagram 

The relationships between the components can be depicted on a functional flow 
diagram (FFBD) after completing the functional hierarchy. Defining all of the 
relationships within a system supports a detailed functional decomposition. Figure 15 is 
an example of a FFBD of the National Aeronautics and Space Administration’s 
(NASA’s) Space Transportation System (STS) Flight Mission (Parnell, Driscoll, and 
Henderson 2011). However, the limitation of the functional flow diagram is the inability 
to identify interfaces of the components. An enhanced functional flow block diagram 
(EEFBD) represents three critical aspects of systems modeling: flow, data interactions 
and resources. An EFFBD is a variation of the FFBD that also represents the behavior of 
a system (Buede 2009, 93). 
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Figure 15. Functional Decomposition for the Top Level of the STS Flight 

Mission 



Source: Parnell, Gregory S., and Driscoll, Patrick J., and Henderson, Dale L. 2011, 
Decision Making in Systems Engineering and Management. Hoboken, NJ: John Wiley & 
Sons, 321. 


c. Integrated Definitions for Functional Modeling 0 

The IDEFO model provides the alignment of functions to components. The IDEFO 

language is a method of describing the system’s processes and activities. There are 14 

methods in the IDEF suite. IDEFO’s purpose is for modeling functions. IDEFO is a 

method of functional decomposition inputs, controls, outputs, and mechanisms (ICOM) 

that address the interaction of the system with other systems. It can describe the 
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hierarchical functions of the system with the IDEFO hierarchy, and starts at AO with the 
first tier functions to Al, A2...Ai, the second tier, and All, A21...Aij, the third tier 
functions (Parnell, Driscoll, and Henderson 2011). The IDEFO models are used to 
decompose a system to show stakeholders all of the ICOMs that are involved in 
performing a function. 


Figure 16. A Generic IDEFO Model 
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Activity 
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Source: Parnell, Gregory S., and Driseoll, Patriek J., and Henderson, Dale L. 2011, 
Decision Making in Systems Engineering and Management. Hoboken, NJ: John Wiley & 
Sons, 44. 


Figure 16 shows a basic building block of an IDEFO model. The box represents a 
function that the system will be performing. The arrows coming down from the top represent 
the controls that specify the conditions needed for the function to perform. An example is a 
rules of engagement directive in Afghanistan. It dictates how military personnel react to 
contact. The arrows on the bottom are the mechanism that performs the functions. The 
identification of the mechanism to the function is important to creating the allocated 
architecture. The arrows on the left coming into the box are the inputs. They are the current 
state prior to the function being executed. The arrows leaving the box are the outputs that are 
transformed as a result of the execution of the function. The outputs may also be an input to 
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other functions within the IDEFO (Parnell, Driscoll, and Henderson 2011). Figure 17 shows 
a more complex IDEFO model of an elevator system. 


Figure 17. Elevator System External Systems Diagram for Operational Phase 
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Source: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: John 
Wiley & Sons, 58. 


2. Physical Architecture 

An important aspect of architecting is to understand which components will 
perform the functions required of the system, which can be achieved by the development 
of the physical architecture. The physical architecture of a system is the description of the 
components that make up the system (Buede 2009). It is hierarchical, like the functional 
architecture described earlier, and helps the analyst to view the overall system down to its 
basic components. 
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There are two ways to view physical architecture, generic and instantiated. Figure 
18 is a generic physical architecture of an elevator from Buede’s elevator case study. It 
depicts the components that make up the elevator. A generic physical architecture 
outlines the hierarchy of the components of the system. Instantiated physical architecture 
provides a more detailed description of the components to enable performance modeling 
of the system. 


Figure 18. Generic Physical Architecture from the Elevator Case Study 
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Source: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: John 
Wiley & Sons, 256. 
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A morphological box is one way to assist in developing the physical architecture. 
It is a technique using a matrix to list the components of the system. It is used to break 
down a system into segments as defined by the generic physical architecture. Then, 
details about the components are filled in to complete the matrix. The detailed box 
becomes the instantiated physical architecture (Buede 2009). The morphological box 
allows the analyst to see the details of each of the component and create the best 
combination for the system. For instance, the example shown in Table 2 is of a vehicle 
needed for a mission. Components of the vehicle would be listed on top. 


Table 2. Example of a Morphological Box for a Vehicle 


Tire Size 

Gas Tank Size 

Engine Size 

16" 

lOgal 

4 Cylinder 

18" 

15 gal 

6 Cylinder 

20" 


8 Cylinder 


The tire size, the gas tank, the engine size would be some of the components for 
consideration of a vehicle. Based on this example, there would be 3x2x3=54 different 
vehicle combinations to consider. A real world consideration for a vehicle would have 
many more combinations. 

3. Allocated Architecture 

The final piece of architecting is the development of the allocated architecture. 
The allocated architecture is the integration of the functional architecture and the physical 
architecture to ensure the right components are doing the right functions. It also defines 
how the system will interact with the external systems. It is important that the 
architecture meets the requirements of the stakeholders and gains their approval. The 
allocated architecture will provide the overall description of the system. 

The allocated architecture will be used to model the entire system. This 
architecture will provide the traceability of the system effects to its objectives for NOSs. 
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Traceability of the model would help identify the cause of deviation from the intended 
system effects and actual system effects. 


H. RECENT MODELING OF NON-OBSERVABLE SYSTEMS FOR 

SIMULATIONS 

Turner’s research in 2014 is the one of the first known work on modeling of a 
NOS for simulations. Turner (2014) proposes the following method to address the current 
gap in literature of an approach to decompose the system, identify relationships that 
impacts the system in a traceable and defensible manner. 

• Utilize SMEs to decompose the system and assign impact relationships 
between measures 

• Determine importance of relationships through analysis 

• Based on relationship importance, decide how the entity is represented and 
to what fidelity based on a selection scheme 

• Compare results to impact relationships (Turner 2014, 105). 

As mentioned earlier in the chapter, decomposition of the system is an important 
aspect of the SE process. SE has several methods of decomposing a system. The two 
basics are functional and physical decomposition to understand what functions the system 
will perform and which component will perform them. 

Turner (2014) uses a mathematical graph presented by Green (2001) during a 
Military Operations Research Society (MORS) on measures of effectiveness for 
command and control. The approach uses a mathematical graph to show the different 
levels of a system. The top level is the objective. The objective defines the purpose of the 
system and the desired behavior. The following level is the effects level. It is defined as 
the measurement of how the system performs within a larger system. The level below is 
performance. Performance measures the individual components tasks, e.g., range and 
speed. The final level is the performance parameters. It is the characteristics of the 
system, such as the weight of the vehicle and the wingspan of an airplane. Turner (2014) 
points out that the impact travels from the lowest level of technical performance to the 
highest level, the objective. Figure 19 outlines the different levels and the flow of impact. 


44 



The mathematical graph identifies the levels as the nodes that represent the metrics, while 
the edges represent the relationship between the two levels. 


Figure 19. System Decomposition Graph 


Technical 

Objectives Effects Performance Performance 

Parameters 



Source: Turner, Andrew. 2014. “A Methodology for the Development of Models for 
Simulation of Non-Observable Systems.” PhD diss., Georgia Institute of Teehnology, 

107. 

As we follow the edges beginning with Tl, it may have an impact on the 
performance of PI. The performance measured at PI may impact the effects at El. 
Finally, the effects at El may have an impact of achieving the objectives at 01 and 02. 
Each impact is how the different metrics are related to one another. The impact 
relationships are relating to the contribution of lower-level metrics to higher-level metrics 
that when summed equal unity. It is a SME defined relationship between the different 
levels (Turner 2014). Although the mathematical graph provides a visual of the 
relationships present in the system, it does not represent a functional hierarchy as 
discussed, or the decisions, processes and activities of an organization like an IDEFO 
model (Parnell Driscoll, and Henderson 2011). An IDEFO model is a much more robust 
method of visually representing a decomposed system. 
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GAPS IN CURRENT RESEARCH 


Turner’s (2014) work on modeling of NOSs for simulations is significant because 
it is unique. All other references to a NOS in the body of literature have been to define 
the term and the concepts, not how to build the models or validate them for system use in 
the real world. Turner (2014) identifies a need for an approach to decompose a system. 
Based on the limited i n f ormation within the body of knowledge of modeling NOSs, 
Turner assumes that decomposing a system helps to identify the relationships between the 
metrics that have the most impact on the system. He uses a mathematical graph to display 
the relationship between metrics. 

Finally, Turner (2014) identifies two areas of continued work in the field of 
modeling of NOSs for simulation at the end of his research. It is in these areas where 
further contribution to the body of knowledge is made and provides the following: 

• Better transition from system definition to impact variable decomposition 

• Proper development of structure for decomposition 

Again, SE methods will be used in this research to continue the previous work to 
improve the method of validation of models of NOSs so it is traceable and support 
current SME validation methods. 

J. VALUE MODEL 

Value modeling provides a quantitative model that provides stakeholders feedback 
on what they value as the most important functions of the system. The value modeling 
process provides an opportunity for stakeholders to become more involved in the model 
development. For this research, the value model is used to assess the impact of the 
functions on the entire system given the weight placed on the function by the stakeholders. 

The value model built for this research uses the functional analysis to determine 
functions, objectives, and measures. Parnell, Driscoll, and Henderson (2011) define steps 
to creating a value model as quoted here: 

• Identify the fundamental objective 

• Identify functions that provide value 
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• Identify objectives that define value 

• Identify value measures 

• Discuss the value model with key stakeholders (327). 

The value hierarchy is created using the steps identified above. Figure 20 shows 
the structure of a value hierarchy. The fundamental objective is at the top. The next level 
shows the functions required to be performed to meet the functional objective. The 
objectives below the functions provide a preference of whether the stakeholders want to 
maximize or minimize the objectives that define the value. The lowest level is the value 
measures that are aligned with the objectives. The values measures can be collected either 
directly or by proxy (Kirkwood 1997). Proxy measures would be taken for the effects of 
the interaction between the system and the external system because it is non-observable. 


Figure 20. Structure of a Value Hierarchy 



Source: Parnell, Gregory S., and Driscoll, Patrick J., and Henderson, Dale L. 2011, 
Decision Making in Systems Engineering and Management. New Jersey, John Wiley & 
Sons, 329. 
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K. SUMMARY 


The M&S community continues to find ways to meet the challenges of modeling 
complex systems that are difficult to predict. Several MDPs are presented in the 
literature; however, the commonality among all of the MDPs is the need for a conceptual 
model validation. The need for a well-structured and validated CoM takes even more 
prominence during the operational validation of NOSs. The concept of a NOS is not well 
defined within the M&S domain. Other fields, such as control theory and fault tolerance 
domains, have used the term in similar ways. Control theory uses observability to address 
the internal state of the system inferred by its outputs (Kalman 1959). Fault tolerance 
uses it to describe a failed system where the system is unobservable because it does not 
keep a record of its requirements (Buede 2009). Sargent (2010) applies the term NOS “as 
not possible to collect data on the operational behavior of the problem entity (system), 
thus there is not a high degree of trust in the model.” Other examples in literature refer to 
future systems with little or no knowledge to be designed, modeled and validated as 
NOSs. 

Current methods of validation of NOSs have primarily been through subjective 
validation techniques, such as face validation (Turner 2014). There is a need to find 
another method of validating models of systems by ensuring it is traceable and 
defensible. Recent attempts at modeling NOSs for simulation have reinforced the 
importance of a well-structured CoM. This research is the first known attempt to ensure 
that multiple validation methods are used for building COMs of systems to support 
operational validation ensuring traceability and defensibility. The use of SE processes 
improves the modeling of these systems for validation. The SE process uses functional 
and physical decomposition methods to identify relationship and use allocated 
architecture to ensure system functions are performed by the correct component. While 
the mathematical graph is a simple way to identify how lower level of metrics affects the 
higher, SE models, such as the IDEFO model, shows the complexity of a system in 
greater detail. Finally, a more analytical method of assigning impacts of the different 
functions and components is the use of the multi-objective decision analysis (MODA) 
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techniques. SMEs are still heavily involved in a MODA and have a method of tracing 
their values to the model. 

Finally, Buede’s (2009) description of the interactions of the system to external 
systems provides a visual of the system and how it impacts the external system. This 
interaction occurs during the execution of the simulation during the MDP. The validation 
of the CoM improves the expectation of the system prior to the execution of the 
simulation. The improved understanding ensures analysts and DMs are able to interpret 
the results of the simulation even with limited or no observation of system’s behavior 
during the simulation. Using Sargent’s (2001) MDP and SE concepts as a foundation of 
understanding improves the conceptual model traceability to the components, and 
facilitates greater SME involvement with conceptual model development. The end 
product is a validated model of a system, in which DMs can rely on to make critical 
decisions. 
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III. IMPROVED CONCEPTUAL MODEL METHODOLOGY 


The ICoMM introduced in this dissertation focuses on improving the structure of 
the CoM during the MDP. The improved structure better facilitates the use of face and 
traces validation techniques for CoM validation and supports operational validation of 
NOSs. The basis of this method is the continuation of previous research on development 
of models for simulations of NOSs by Turner (2014). In 2014, Turner states that his 
research lacks a clear methodology to improve transition from system definition to 
impact variable decomposition. Turner (2014) defines impact variables as “the 
relationship of lower level metrics contributing to higher-level metric” (111). He also 
identifies the need to conduct further research into proper development of its [model] 
structure (Turner 2014). 

ICoMM improves the structure of the conceptual model by SE and SA to 
Sargent’s evolved MDP. A model is a representation of a system. ICoMM presents the 
idea that SE processes should be used to build the model of a system. SE “focuses on 
identifying customer needs and functionality early in the development process, 
documenting requirements, then proceeding with design synthesis and system validation 
while considering the complete problem” (INCOSE 2015). A CoM describes system 
functions and the execution of the functions to achieve the fundamental objective (Law 
2007). SE and SA methods support the ICoMM by identifying the components of their 
interfaces and concept of execution. 

The value of ICoMM is an improved structure of the CoM that facilitates the 
identification of a single fundamental objective, early inclusion of SMEs, and 
identification of external system functions that affects the fundamental objective. 
Identification of a single fundamental objective focuses the system and its components to 
one overarching objective. ICoMM reduces the confusion of performance measurements 
leading to multiple objectives by facilitating traces of measurements and sub-objectives 
leads to the fundamental objective. All the components are aware of its contribution 
towards fundamental objective. SMEs are required for the development of the CoM early 

in the MDP. SMEs weights of functions are documented and then evaluated at the end of 
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the simulation. The CoM must be reevaluated if there is a deviation from the actual 
output from the output envisioned by the DM. The first item to be investigated is the 
weights of the functions provided by the SMEs. The SMEs are held accountable by the 
weights of the functions assigned by the SMEs. The identification of the external system 
shows the potential of how the external system interacts with the system to either enhance 
or degrade the achievement of the fundamental objective. The interaction between the 
two systems may be non-observable; a well-structured CoM helps to identify points of 
interaction. 

A. CONCEPTUAL MODEL DEVELOPMENT PROCESS DEFINITION 

This chapter revisits Sargent’s (2001) evolved MPD to focus on the CoM phase 
and CoM validation of the simulation world. fCoMM presents a generic SE process 
model to include system architecting in the development of the CoM. A value model is 
also included to identify SME inputs into the development of the CoM. SME 
involvement in the development of the CoM is critical early in the MDP, rather than 
providing expertise at the conclusion of a simulation. The following steps are used in 
fCoMM to develop the structure of the CoM: 

1. Understanding the Operational Concept 

a. Stakeholder Analysis 

b. Requirements Analysis 

2. Develop System Architecture 

a. Functional Architecture Development 

b. Physical Architecture Development 

c. Allocated Architecture Development 

3. Gather SMEs Values 

a. SME Weight of Functions 

b. Impact of the Functions 

4. Model Exploration of Non-Observable Systems 

Following Sargent’s (2001) evolved MDP, we concentrate on the process between 
systems theories and conceptual model phases. His evolved MDP simply has the term 

modeling between system theories and conceptual model. ICoMM updates the model to 
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include Buede’s (2009) “Architecture development in the engineering of a system” model 
by replacing the simple “modeling.” ICoMM provides a fills the gap that Turner in his 
research states is needed to investigate a better transition from system definition to 
impact variables. Figure 21 shows the “inclusion of architecture development in the 
engineering of a system” (Buede 2009) as a part of Sargent’s evolved MDP. It also 
identifies the two validation techniques, face and traces, that are used to validate CoMs. 


Figure 21. Introduction of Systems Engineering and Systems Architecture in 

the Model Development Process 



Adopted from: Sargent, Robert. 2001. “Some Approaches and Paradigms for Verifying 
and Validating Simulations Models.” Proceedings of the 2001 Winter Simulation 
Conference, 109. 


B. IMPROVEMENT OF THE CONCEPTUAL MODEL 

An initial understanding of the system is needed to transition the system from the 

real world to the simulation world. The real world identifies the need for a system to 
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address a deficiency (Blanchard and Fabrycky 2006). ICoMM assumes that the need has 
been identified and requires a system to be built to address the deficiency. ICoMM 
facilitates the identified needs of the system from the real world to enter the simulation 
world to build models of the system to help DMs gain insights and make decisions. 

1. Operational Concept 

The process begins by establishing an operational concept. A system is created to 
execute functions to achieve an objective in the real world. The operational concept 
provides a general picture of the functions, components, and the objectives of the system. 
It provides a description of the functions and the products produced by the system. It 
facilitates understanding of the system and the context and its execution as directed by 
the DM. The operational concept includes scenarios that describe how the system 
interacts with external systems (Buede 2009). It is a shared idea of the system among all 
of the stakeholders (Buede 2009). The only outcome of this phase is a shared 
understanding of the system. 

The established operational concept of the system is used by ICoMM to begin 
developing the CoM. The operational concept establishes the functions and the 
components of the system, as well as descriptions of the external system and the context 
in which the system operates. Figure 22 shows the system and its interactions with the 
external system. The interactions with the external system can be in one direction or both 
directions. The entity that provides the context for the system is only in one direction. 
The context scopes and bounds the system’s activities during the execution of the system 
functions. The system cannot affect the entity providing the context. The operational 
concept defined in this phase is the basis for which to establish the structure of the CoM. 
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Figure 22. Depiction of the System, External System, and Context 



System 



Source: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: John 
Wiley & Sons, 50. 


a. Stakeholder Analysis 

Stakeholder analysis is the initial step in developing the operational concept. This 
step identifies the objectives, the functions, components, constraints, and values of the 
DM (Parnell, Driscoll and Henderson 2011). Stakeholder analysis can be conducted in 
many ways, such as interviews, surveys, and focus groups. This dissertation uses the 
operational concept established by SE analysis cohort 17, Team A for their master’s 
thesis. 


b. Requirements Analysis 

Another aspect of the operational concept is the requirements analysis. 
Requirements analysis addresses the need and objectives of the system (Buede, 2009). 
The top requirement is the overall requirement of the system. All the stakeholders support 
this requirement. This requirement requires the interaction of several subcomponent 
systems, as well as external systems. 
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An introduction in this dissertation is that ICoMM also adds the requirements of 
the external system as part of the requirements analysis. External systems also have 
requirements that must be met to support the top requirement. Figure 23 shows a 
depiction of requirements analysis. The external system is identified in a gray box, but 
shows a linkage between the top requirements and the external system requirement. This 
is an extension of Figure 21, Buede’s (2009) “depiction of system, external system, and 
context” designing the system to include the external system. 


Figure 23. An Example of a Requirements Analysis with External System 
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2. System Design 

Designing of the system begins once the operational concept has been defined 
(Buede, 2009). Systems design is the transformation of a system in the stakeholders’ 
minds into models into visual formats (Buede, 2009). ICoMM supports the establishment 
of the concepts within the minds of the DMs into visible CoMs for simulations. Systems 
design takes the operational concept presented earlier and conducts decomposition of the 
functional and physical representations of the system (Buede, 2009). The functional 
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architecture identifies the functions that must be executed to meet the requirements. The 
physical architecture identifies the physical components that are part of the system. The 
allocated architecture identifies the allocation of which physical components will execute 
the functions to meet the identified requirements (Buede, 2009). 

Figure 24 shows how once the operational concept of the system is developed, the 
decomposition and the integration begin. The functional and physical decomposition of 
the system is performed by the architecture. Buede (2009) describes “the functional and 
physical architectures are developed in parallel to provide more meaning when integrated 
to form an allocated architecture” (27). 


Figure 24. Architecture Development in the Engineering of a System 



Source: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: John 
Wiley & Sons, 28. 


ICoMM integrate the systems architecting process into the MDP to improve the 
structure of the CoM, as seen in Figure 1. Incorporating systems architecture into the 
MDP to develop the CoM ensures that the models will more accurately represent the 
system. In addition, establishing a structured methodology to build the CoM increases the 
traceability of the model as ICoMM demonstrates in Chapter IV. 
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a. Functional Architecture 

ICoMM uses functional architecture to define what the system must do. The 
functional architecture is a decomposition of the system’s top-level functions (Buede 
2009). ft identifies the functions that the system is required to execute. A functional 
hierarchy is created to show the lower-level functions and the link to the top-level 
function it supports as shown in Figure 25. Once again, ICoMM integrates the functions 
of the external system to show its relationship to the system. The functions of the external 
system influence the execution of the top-level function. 


Figure 25. An Example of the Functional Hierarchy 
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Next, ICoMM identifies the sequence of the function by using the EFFBD as seen 
in Figure 26. The EFFBD displays the functions and the sequence it is performed. The 
EFFBD provides dynamic information, which the IDEFO model cannot display. Figure 
25 shows that the two functions, perform air co nn ector and perform surface connector. 
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can be executed simultaneously, while the perform forward logistics function occurs 
afterwards because the forward logistics actions of distributing aid cannot be conducted 
until the aid arrives to the forward logistics sites. The EFFBD is the method ICoMM uses 
to display this information. 


Figure 26. An Example of an EFFBD 



b. Physical Architecture 

The components of the system are identified following the identification of the 
functions. The components are the physical aspects of the system that will execute the 
functions. Figure 27 shows an example of a physical architecture that identifies the 
components of the system. ICoMM uses a generic physical architecture that defines the 
physical hierarchy in general terms to understand what components are included in the 
system. 
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Figure 27. An Example of a Physical Architecture 



c. Allocated Architecture 

The allocated architecture is built after the identification of the functions and the 
components that will execute the functions. As seen in Figure 28, ICoMM maintains the 
concept described in Buede’s (2009) description of system, external system, and context. 
Functions and the components are allocated within the system to interact with the 
external system. ICoMM uses the information about the external system to improve the 
allocation of the functions to the components. For example, a function of delivering aid 
would not be necessary for interacting with the insurgency, but provide the necessary 
security. 
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Figure 28. The Allocated Architecture within Designing of a System 



Adapted from: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: 
John Wiley & Sons, 50. 


ICoMM uses the IDEFO to display the allocated architecture visually. The IDEFO 
shows the system design to include the functions as inputs and outputs, the physical 
components as the mechanism to perform the functions, and the context of the system as 
the controls. Figure 29 is an example of the IDEFO model displaying the input and 
output, the mechanisms, and controls. The allocated architecture provides the structure 
that allows the traceability from components to functions, and ultimately, to the 
fundamental objective. The traceability provided ICoMM improves the facilitation of 
traces validation method of conceptual models. 
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Figure 29. An Example of an IDEFO Model 



3. Subject Matter Expert Values 

Finally, ICoMM includes a value to model to document SMEs’ values of 
functions that will be executed by the system. Traditionally, involvement of SMEs for 
model validation was at the end of the operational validation. ICoMM ensures that the 
SMEs provide weights for the functions by their values of importance. These weights are 
also identified as the impact that the function will have on the output of the system. It is 
the weights identified by the SMEs that will be evaluated post simulation to conduct 
operational validation of the NOS. Figure 30 shows an example of how value curves are 
included in Buede’s example of the elevator study. Buede (2009) uses stakeholders to 
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solicit their values. Although the inputs of the stakeholder values are important, it is the 
solicitation of SMEs’ values of functions of the system that is the basis of ICoMM. 
ICoMM facilitates face validation of the conceptual model where SMEs are required for 
validation. 


Figure 30. Objective Hierarchy with Value Curves 



Source: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: John 
Wiley & Sons. 186. 


C. SUPPORTING OPERATIONAL VALIDATION OF NON-OBSERVABLE 
SYSTEMS 

The idea of a CoM is not new. What is novel of ICoMM is the integration of SE 
methods into the MDP to build CoMs and to improve both conceptual and operational 
validations. As seen in Figure 31, ICoMM addresses the operational validation needs of 
systems that meet the criteria to be classified as a NOS. 
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Figure 31. Execution of Simulation of a NOS 



Adopted from: Sargent, Robert. 2001. “Some Approaches and Paradigms for Verifying 
and Validating Simulations Models.” Proceedings of the 2001 Winter Simulation 
Conference, 109. 


Figure 32 shows the flow of an MDP for a NOS. The only information about the 
model of the system is the inputs and outputs produced by the simulation. The inputs are 
allocated functions and components of the CoM. The outputs are the results of the 
simulation. The outputs may match or deviate from the intended output. If the output 
matches the intended output, then it is classified as an observable system and the original 
conceptual model is operationally validated. The model can be presented to the DM to be 
used for future scenarios. If the output is a deviation of the intended output, then 
operational validation of the model is infeasible and it is classified as a NOS. The only 
method to provide an operational validation of a NOS is through model exploration. 
Thus, the CoM must be reexamined. This methodology is repeated until the output 
matches the CoM through model exploration. The model of the system is determined to 
be a failure if the output does not converge to a correct model after multiple iterations. A 
new system should be designed to address the deficiency. If applied as described in this 
methodology, ICoMM provides an effective means to conceptually and operationally 
validate future CoMs throughout the MDP. 
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Figure 32. Reference Back to the Conceptual Model 
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IV. APPLICATION OF THE IMPROVED CONCEPTUAL MODEL 

METHODOLOGY 


To demonstrate the applicability of ICoMM, an analysis of developing a validated 
CoM of a future DOD HA/DR mission is presented. As mentioned, this dissertation 
leverages Sargent’s (2001) evolved MDP and the inclusion of SE methods into the MDP 
process to develop ICoMM. It is a continuation of the work of Andrew Turner’s 
“Methodology for the Development of Models for Simulation of Non-observable 
Systems.’’ Turner (2014) states the need for an improved method for system definition 
and further research into the proper development of its structure that lacks in his research 
(330). Systems definition is “the identification of the system of interest and decomposing 
the system so it can be translated into model formation’’ (54). The HA/DR mission was 
chosen based on two criteria. First, the scenario is based on missions DOD will execute 
in the future. HA/DR missions are dynamic and each mission is different. Although 
similar HA/DR missions may have been executed, future interactions between external 
systems and the context in which the system operates in will differ. Second, the scenario 
facilitates the comparison of ICoMM to previous research conducted by Andrew Turner. 
This dissertation presents ICoMM as a way to improve both systems’ definition and 
structure of the model to demonstrate its contribution. ICoMM furthers the research by 
strengthening the validation of the CoM and its support to operational validation of a 
NOS. This dissertation is not intended to be a criticism of the previous research, but 
rather the acknowledgement of the novel concept of modeling a NOS and addressing a 
necessary expansion to validate models of a NOS. It is the intent of this dissertation to 
use ICoMM to develop models of systems that are trusted by DMs to make critical 
decisions. 

This chapter applies ICoMM to a scenario that requires a CoM to be developed 
and validated and to be executed in a simulation. The CoM is developed with SME input 
and improved structure to be traceable for model exploration after the execution of a 
simulation. The identification of system need is already established in the scenario. 
ICoMM is applied from the operational concept to conduct system definition and 
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decompose the system to build the functional, physical, and allocated architectures. 
Finally, ICoMM define the impact of each of the functions of the system with the value 
model. 

A. HUMANITARIAN ASSISTANCE / DISASTER RELIEF SCENARIO 

SELECTION 

This dissertation investigates a HA/DR scenario to compare previous research of 
modeling of NOSs by Turner. The scenario is based on a master’s thesis by the Naval 
Postgraduate School, Systems Engineering Cohort 17 in 2011 about the influence of 
foreign HA/DR in a coastal nation (Alexander et al. 2011). Again, this scenario was 
chosen because this research is a continuation of Turner’s research. 

The HA/DR scenario meets the definition of NOSs defined earlier as non-ability 
to observe the behavior of the interaction of two systems and the result is the deviation of 
actual effects from the intended effects. The data of the interaction between the system 
and the external systems cannot be directly collected during the execution of this 
scenario. The operational validation of this model is infeasible for this scenario due to its 
classification as a model of a NOS. Thus, the operational validation is conducted by 
model exploration of the CoM and face validation methods relying on SMEs. 

The scenario is set in the future in a conceptual environment with very little 
information of the population and their social issues. The military system conducting the 
HA/DR effort includes components, such as the T-Craft, a high-speed/high-volume cargo 
carrier not part of the current U.S. Naval fleet. The success of the operation depends on 
the satisfaction of the population receiving the aid and the reduction of the population 
into criminal behavior (Alexander et al. 2011). These two success criteria are based on 
the interaction between the military system and the local populous. 

HA/DR is one of the very important missions that the U.S. military has been 
participating in for many years. In 2013, the United Nations reported 880-loss events 
worldwide (Munich RE 2014). A graphic depiction is seen in Figure 33. The United 
States has been the largest provider of humanitarian assistance by contributing $4.7 
billion worldwide. The largest recipients of U.S. assistance have been sub-Saharan 
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countries in Africa. For the past decade, sub-Saharan countries received 59% of overall 
U.S. aid (Global Humanitarian Assistance 2013). 


Figure 33. Loss Worldwide Event 2013 
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Alexander et al. (2001) also states that the group’s reason for selection of this 
scenario is that OPNAV N8F directed a study into the designing of systems architecture 
to support a HA/DR mission for a developing nation. The design team was requested to 
design and assess a system that provides continual, multi-year support for a host nation’s 
efforts to ensure security and stability during a HA/DA mission. The primary goal was to 
develop a “regional stability systems architecture.’’ This system would consist of a sea 
base and sea base connectors with the following capabilities: 

• Disrupt social interruption activities and provide humanitarian aid through 
the use of joint and coalition naval forces 

• Address potential local population support for disruptive forces 
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• Address the reasons for enemy forces to engage in disruptive activities 
(Office of the Chief of Naval Research 2011) 

The concept of the HA/DR mission is based on Expeditionary Warrior 10 (EWIO) 
wargame scenario developed at the USMC Wargaming Division. The overarching 
questions to answer are, “how well is aid being distributed to the population and the 
effect of HA/DR on the population” (United States Marine Corps Wargaming Division, 
Marine Corps Warfighting Laboratory 2010). ICoMM builds a conceptual model to 
address the questions posed by OPNAV N8F and the USMC Wargaming Division by 
identifying the functions of the system, the external system, and their interactions. 

B. SCENARIO OVERVIEW 

The HA/DR scenario presented by Alexander et al. (2011) is set in 2022. A 
devastating storm greatly damaged the western African region with great destruction and 
heavy flooding. The Country of Orange (COO), at the limits of its internal emergency 
resources, requested foreign assistance to the United Nations (UN). The United States, 
which is a member nation of the UN, responded to the request for assistance. The DOD 
was tasked to provide immediate support to the disaster region by sending a Naval 
expeditionary strike group (ESG) composed of a Marine expeditionary unit (MEU) 
capable of conducting HA/DR missions. ICoMM is applied to this scenario to improve 
the structure of the CoM by including the external system and context to the 
architectures. 

C. OPERATIONAL CONCEPT DEVELOPMENT 

A review of the operational concept for the HA/DR scenario is conducted to 
identify the system, external system, and potential interactions. The operational concept 
defines how the military systems will be used to interact with local systems during the 
HA/DR operation. 

The U.S. military, with support from other-government organizations (OGOs), 
such as the State Department’s United States Agency for International Assistance 
(USAID) and non-govemment organizations (NGOs), are called to provide aid to the 

people of Orange. The main effort of the HA/DR mission will be from the sea due to 
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heavy damages to Orange’s infrastructure. An off shore sea base will start the two stage 
relief effort. In the initial stage, aid will be transported from a sea base to a forward 
logistics site (FLS) and to the forward logistics satellite site (FLSS). The second stage is 
to deliver the aid from the FLSS to the local populous. Figure 34 shows the flow of the 
operation and an overview of the mission. 


Figure 34. Operational Overview of the HA/DR Mission 



Source: Alexander et al. 2011. “Influence of Foreign Humanitarian Assistance/Disaster 
Relief in a Coastal Nation.” Master’s thesis, Naval Postgraduate School, 7. 


Four courses of action (COAs) were presented for the delivery of aid. The courses 
of actions differ on the matter of who will directly deliver the aid to the local populous. In 
the first COA, the military delivered aid material to the FLS only and the non-military 
organizations would provide delivery to the FLSS, and subsequently, to the populous. For 
COA 2, the military would deliver to all the FLSs and the FLSSs. This COA would use 
more military resources; however, but would ensure that security was provided to the 
people. For COAs 3 and 4, the delivery of aid would be conducted in stages to the FLS 
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first and then to the FLSS. The difference between COAs 3 and 4 is that local security 
would not be present at the FLSS in COA 3. Figure 35 displays the different COAs. 


Figure 35. Four Courses of Action Overview 
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Source: Alexander et al. 2011. “Influence of Foreign Humanitarian Assistance/Disaster 
Relief in a Coastal Nation.” Master’s thesis, Naval Postgraduate School, xxxvi. 


1. Course of Action Decision 

COA 2 is selected for the proof of concept following the work of Turner’s (2014) 
research to demonstrate the modeling NOSs for simulations. Modeling of the other COAs 
requires a model for each of the COAs, which is redundant and time consuming. Another 
reason for COA 2 selection is that the SE Cohort 17 in their capstone project 
demonstrated that COA 2 was the optimal COA for their research. COA 2 is used to build 
the system architecture to demonstrate its traceability. COA 2 is also simplest in concept. 
All the platforms directly deliver aid to the FLS and the FLSS with security. The air 
connectors deliver aid to the FLSS located in remote locations away from access to the 
sea. The surface co nn ectors deliver to the FLS, which are closer to access from the sea. 
Figure 36 shows the path the surface connectors use and Figure 37 shows the air 
connector path to deliver aid. 
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Figure 36. Surface Connector Path to the FLS 



Source: Alexander et al. 2011. “Influenee of Foreign Humanitarian Assistanee/Disaster 
Relief in a Coastal Nation.” Master’s thesis, Naval Postgraduate Sehool, 55. 


Figure 37. Air Connector Path to the FLSS 



Souree: Alexander et al. 2011. “Influenee of Foreign Humanitarian Assistanee/Disaster 
Relief in a Coastal Nation.” Master’s thesis, Naval Postgraduate Sehool, 57. 
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The flight paths of the air connectors vary based on the number of platforms and 
the consumption of fuel to travel to the FLSS. The flight paths and the course the sea 
connectors take to the logistic sites were not calculated because it is not in the scope of 
this research. This research does not address the optimal travel paths or network analysis. 

2. Identification of Systems 

The first step in ICoMM is to identify the systems involved in the scenario. Figure 
38 provides a picture of the identified system, external system, the context in which they 
operate and the relationships between them. The two main systems in this scenario are 
the actual system that we know and the external system that the system will be impacting. 
The U.S. military HA/DR unit is the system with available data and the DM has the 
ability to change its composition or COA. These decisions are based on the impact the 
system has on the external system. The external system in this scenario is the COO. The 
HA/DR mission unit conducts HA/DR operations in the COO and must determine if its 
actions are achieving the intended effects as envisioned by the DM. The double-headed 
arrow between the two systems is used to show that the actions of both systems may 
influence each other. 


Figure 38. Systems Relationship Diagram 


System 


External System 
Impacted by the "system" 



Adapted from: Buede, Dennis. 2009. The Engineering Design of Systems. Hoboken, NJ: 
John Wiley & Sons, 50. 
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a. The Country of Orange 

Orange is an African nation strategically situated next to the Gulf of Orange on 
the west. Figure 39 shows the three major population centers of the country of Orange. 
Two major population centers are in state number one and one population center in State 
number two. All three major population centers can access the Gulf of Orange. 


Figure 39. The Geography of Orange 
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Adapted: Alexander et al. 2011. “Influenee of Foreign Humanitarian Assistance/Disaster 
Relief in a Coastal Nation.” Master’s thesis, Naval Postgraduate Sehool, 4. 


Orange politically has many internal problems. It is a diverse country with a 
population of 179 million divided into 250 different ethnic groups. The majority of the 
population is divided into 70 million Muslims in the north and 70 million Christians in 
the south. In the north, radical Islamic groups, such as Al Qaeda in Islamic Maghreb 
(AQIM), is very active, while a growing number of participants in the Movement for the 
Emancipation of Southern States insurgency in the south threaten the stability of Orange. 
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The storm has had devastating impact on the population of Orange. Table 3 shows 
the breakdown of the population and the effects of the devastating storm. The storm had 
the most effect on the two western states of 1 and 3. State #2 in the eastern most region 
was least affected. However, State #2 also host hostile feelings towards the GOO and 
may conduct anti-government activities to influence the populous to turn against the 
Govern m ent of Orange (GOO). 


Table 3. Breakdown of the Population and the Effects of the Storm 


State 

Population 

(mil) 

# Dead 

# Injured 

# Diseased 

# Displaced 

Total Affected 

Attitudues 

toward 

mission 

1 

4.1 

85 

750 

2000 

97,000 

243,000 

Neutral 

2 

1.7 

5 

150 

300 

17,000 

25,000 

Hostile 

3 

5.2 

35 

350 

600 

19,600 

34,000 

Neutral 

Total 

11 

125 

1250 

2900 

133,600 

302,000 



b. The Humanitarian Assistance/Disaster Relief Mission Unit 

The DOD directed a Naval ESG to execute the HA/DR mission in support of the 
COO. The ESG sent a MEU to begin an initial push into the COO with its forces and 
capabilities. The MEU provides important capabilities that will be needed to execute the 
mission. The MEU is comprised of 2,200 Marines and has the capabilities to provide air 
connection and surface connection, as well as internal security. The sea base conducts 
command and control (C&C) of the mission. 

The sea base is comprised of three amphibious ships: A Wasp class Landing 
Helicopter Deck (LHD), a San Antonio class Landing Platform Dock (LPD), and a Dock 
Landing Ship (LSD). The LHD, being the largest of the three ships, will provide the 
overall C&C. All three ships carry vehicles with a capability to connect to the FES and 
the FLSS. The air connector duties will be conducted by three different aircrafts: MH 53, 
Sea Stallion, MV-22 Osprey, and the SH-60B, Sea Hawk. The surface connection will be 
performed by two platforms, the Landing Craft Air Cushion (LCAC) and the Landing 
Craft Utility (ECU). Figure 40 shows the different platforms that will be executing the 
HA/DR missions. The specifications of all the platforms are listed in Appendix B. 
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Figure 40. MEU Vehicles Participating in the HA/DR Mission 


Marine Expeditionary Unit HA/DR platforms 
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Adapted from: Alexander et al. 2011. “Influenee of Foreign Humanitarian 
Assistanee/Disaster Relief in a Coastal Nation.” Master’s thesis, Naval Postgraduate 
Sehool, 44. 


A forward logistical site also supports the HA/DR mission for the DOD. The Joint 
Staff publication 3-35 defines the Naval FLS as the following: 

An overseas location, with port and airfield facilities nearby, which 
provides logistic support to naval forces within the theater of operations 
during major contingency and wartime periods. (IP 3-35 2013, GL-7) 

The HA/DR mission to support the COO establishes two types of logistics sites, a 
FLS and a FLSS to support the distribution of aid to the local populous. The FLS and the 
FLSS work with government and non-government agencies to deliver and distribute aid 
to those who cannot travel to the logistic sites. The FLS is the larger of the two types and 
is established near three major population centers of A, B and C and near watercraft entry 
points. There are no FLS in State #3 due to the lack of a major population center. The 
location of the FLSS is also based on the distribution of the population throughout the 
country. There are 41 FLSSs to support the HA/DR mission. Figure 41 depicts the 
locations of the FLS and the FLSS. 
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Figure 41. Locations of the FLS and the FLSS 



Assistance/Disaster Relief in a Coastal Nation.” Master’s thesis, Naval Postgraduate 
School, 53. 


3. Stakeholder Analysis 

The Unites States and the United Nations have a strategic goal of maintaining 
stability in the region. A lack of response to the disaster may provide a catalyst for the 
increase of hostile sentiment towards the GOO by the local populous. The anti- 
government forces have the potential to increase hostile activities by instigating the 
emotional vulnerabilities of the people. The U.S. government and the United Nations 
provide the context of the operation. The context impacts the system, but the system does 
not impact the context. The Unites States and the United Nations control the behavior of 
the system by issuing strategic guidance, setting rules of engagement, and relaying 
request from the GOO. They can also set strategic requirements for the system. 

Referring back to Figure 38, the diagram provides a general idea of the over 
concept of the mission. It is important to understand the arrow with the two heads 
because it signifies the interaction between the system and the external system, and not 
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just the impact. The identification of which functions are performed by specific 
components and how the system interacts with the external system are conducted during 
the building of the allocation architecture. The interaction between the two systems is 
non-observable and operational validation is infeasible. ICoMM is used to facilitate 
model exploration to support the operational validation of this scenario. 

4. Requirements Analysis 

ICoMM identifies the requirements for conducting the HA/DR mission from the 
operational concept. The requirements products identify the needs of the stakeholders of 
the mission. The stakeholders are anyone who has an interest in the decision to 
participate in HA/DR, execute the mission, and receive aid from the mission. Three levels 
of requirements are identified for this mission. Figure 42 shows the requirements 
hierarchy of the mission. The top level is the primary requirement for the system is to 
conduct HA/DR mission. It is important to all the stakeholders that the HA/DR mission is 
conducted. The HA/DR requirement provides the overall requirement of the mission. All 
the components of the system will be in support of conducting the HA/DR mission. 
ICoMM’s contribution to the requirements hierarchy is the addition of the external 
system’s requirements. It is important to identify the external system’s requirements 
because it has a direct or an indirect relationship to support the top-level requirement. 


Figure 42. Requirements Hierarchy for the HA/DR Missions 
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The HA/DR requirement is supported by four supporting requirements in the next 
level. These supporting requirements are needed to achieve the primary requirement. 
These requirements are to conduct sea base operations, air transport, connect by surface, 
and receive aid. The first three requirements are the needs of the HA/DR mission system 
while the last requirement is the need of the external system. The layout of the 
requirements is designed to show not only the requirement of the system, but the external 
system as well. It provides the stakeholders a graphic display of how the needs of both 
systems support the primary requirement of conducting the HA/DR mission. The lowest 
level of requirements identified in the system is to support the second level requirements. 

The requirements of conducting C&C and logistical operations are under the 
requirement of conducting sea base operations. These requirements were identified to 
ensure that the overall functions of the mission had oversight and resupply was conducted 
to continue the operations for a 15 or an extended 60-day mission. C&C is a subtask of 
conducting sea base operations. It is responsible for overseeing the entire HA/DR 
mission. The other level two requirements do have the responsibility of this requirement. 
The sea base is also the point for resupplying the units participating in the mission. 

There are two requirements to deliver aid to the FLS and the FLSS. First, 
conducing air transport requirement is needed to reach the FLSS that cannot be reached 
by either the sea or surface connectors. The requirements that support the air co nn ector 
requirements are to provide air security for force protection (FP) and delivery of aid to 
the logistical sites. The surface connectors’ requirements are to deliver aid to the FLS 
where it is closer to the water inlets. The surface connectors’ requirements are to provide 
security and delivering aid. 

The last level 2 requirement is to receive aid. This is a requirement for the COO. 
The people of Orange must be able to receive aid for the mission to be successful. There 
is also a level 3 requirement to provide internal security against the anti-government 
forces. 
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D. SYSTEM ARCHITECTURE 


The decomposition of the system occurs during the architecting phase. The three 
types of architecting, functional, physical, and allocated, are discussed in the following 
sections. Functional architecture is created to facilitate the identification of the attributes 
of the systems. Physical architecture is created to identify all the components of the 
systems. An allocated architecture matches the functions to components. Finally, a value 
model is built to identify the functions that SMEs value having the most impact during 
the interaction between systems. Turner (2014) addresses these functions as “impact 
variables” in his research. Again, this research fills the gaps Turner identified in his 
previous work by improving the identification of system definition and the structure of 
conceptual models of NOSs for validation. 

1. Functional Architecture 

The functional analysis begins once the requirements have been identified. It is 
through the functions that the requirements for the systems are met. Figure 43 shows the 
functional hierarch of the HA/DR system. The initial functions are derived from the Joint 
Tactics, Techniques, and Procedures for Humanitarian Assistance doctrine (Department 
of Defense 2001). ICoMM identifies that sub-level functions not mentioned in the joint 
publication. ICoMM also tailored the frinctional architecture in Figure 42 to include the 
functions of the external system, as well as the system, but exclude the function that is 
outside of the scope of the HA/DR mission. This deviation from the joint doctrine 
supports the concept of this dissertation of including the external system and the context 
in the design of the system. 
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Figure 43. Functional Hierarchy 



The overall function of the entire system is to provide regional stability. Regional 
stability is maintained by the next level 2 functions. They provide security, HA/DR, C&C 
and infrastructure repair. Infrastructure repair is blackened because it will not be a part of 
this scenario. No HA/DR mission assets are dedicated for infrastructure repair. The 
external system function of perform Country Orange functions is included because it 
supports providing regional stability. 

2. Enhanced Functional Flow Diagrams 

As described in Chapter 11, the EFFD provides another view of the functions 
compared to the functional hierarchy, ft shows the sequence of the functions that must be 
executed. The sequence of the functions is important to ICoMM because it is another tool 
for model exploration should the NOS deviate from the intended output. The following 
diagrams show the EFFD for the sequence of functions for the top and lower level 
functions as examples. 
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a. Provide Regional Stability 

Figure 44 shows an EFFD to provide regional security to illustrate that the lower 
level functions are conducted simultaneously as noted by the word AND in a white circle. 
However, the external system’s function is depicted on separate parallel line. The 
external system’s functions will be performed simultaneously, but not as part of the 
system. It will support the overall function of maintaining regional stability, but not as a 
part of the system. Again, the provide infrastructure function is blackened because it is 
out of the context of this mission. 


Figure 44. Provide Regional Stability Functions 



Each of the level 2 funetions are supported by level 3 funetions. There are 10 level three 
funetions identified in this study. These level three funetions establish what Parnell ealls 
objeetives, and ultimately, our value measurements (Parnell, Driseoll, and Henderson 
2011 ). 
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b. Provide Security Function 

The provide security function is one of two functions mentioned in JP3-07.6 
(200 f) that this research includes as a level 2 function. The provide security has two level 
3 functions. The functions are to provide security for distribution and internal FP. The 
HA/DR mission is aware of hostile threats in the area and must provide security at the 
FLS and the FLSS while they are unloading aid at the sites. Once they are at the site, it is 
the responsibility of the HA/DR unit to ensure everyone’s safety at the site in conjunction 
with the local security forces. The crosswalk of functions is described later in the chapter 
to demonstrate how level 3 functions indirectly support other level 2 functions. The 
HA/DR unit is also responsible for providing its internal force protection. This function is 
for situations when the co nn ectors are at neither a FLS nor a FLSS. The two functions 
may also be conducted simultaneously due to the continuing nature of the operation. The 
green and grey circles represent inputs and outputs of the function. It is discussed further 
in the allocation section later in this chapter. Figure 45 outlines the security functions. 


Figure 45. Provide Security Functions 
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c. Provide HA/DR Function 

The HA/DR function is the other level 2 function mentioned in JP 3-07.6 
(Department of Defense 2006) added as a part of this research, ft is the function that 
performs the primary HA/DR mission, ft has three level 3 functions, perform air 
connector functions, perform surface connector functions, and perform forward logistics 
functions. The EFFBD shows that the two-connector functions are conducted in parallel 
while the forward logistics function is performed following the two. The air co nn ector 
delivers aid by aircraft to FLSS when other transportation means from the sea base are 
not possible. The surface connector function delivers aid to the FLS near coastal waters. 
The forward logistics function is to aid the flow of aid from the HA/DR mission units to 
the local population. Figure 46 shows the flow of functions to provide HA/DR. 


Figure 46. Provide HA/DR Functions 



3. Provide Command and Control Function 

The C&C function has two level 3 functions. The C&C has two functions, receive 


supply from a higher logistical station and perform the duties as a sea connector. The 
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C&C function ensures that the aid for the population of the COO is first received by the 
sea connectors and is distributed to the air and surface connectors. Figure 47 shows the 
flow of functions required to provide C&C. 


Figure 47. Provide Command and Control Functions 
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As previously mentioned, the functions of the COO are of the external system. 
However, ICoMM identifies the functions of the COO as a part of the overall function of 
providing regional security. There are three level 3 functions associated with the COO: 
provide internal security by the GOO, receive aid, and perform hostile. Functions EXF. 1 
and EXF.2 are performed in parallel. Function EXF.3 is depicted as an OR in a white 
circle to show that it is a function performed as a part of the function of COO, but not in 
conjunction with the other two. The allocated architecture presented later in the chapter 
shows that hostile forces opposing the GOO also has functions that impact the system. 
Figure 48 shows the external system’s flow of functions, specifically for the COO. 
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Figure 48. Provide Country of Orange Functions 



4. Tracing Functions to Requirements 

The input and output requirements were derived from the requirements identified 
in section C4. The inputs are needed prior to the execution of a simulation and the 
outputs are the results of post simulation. Table 4 shows an initial list of input and output 
requirements to provide traceability of functions. The input and output requirements also 
include traceability to the external functions. 
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Table 4. Traceability from Input to Output Requirements to Functions 


Functions 

Input/Output Requirement 

Input Requirements 

Output Requirements 

Functional 

Requirement 

External Interface 
Requirement 

The COO will 
request aid 

Hostile Forces 
maybe present 

The HA/DR mission 
will deliver Aid 

HA/DR mission will 
provide internal 
security 

The HA/DR mission 
will have central 

C&C 

TheCOOwill 

contact US & UN 
Reps for updates 

FUND. Provide Regional Security 

X 

X 

X 

X 

X 

X 

FUN 1, Provide Security 


X 


X 



FUN 1.1 Provide security for distribution 


X 


X 



FUN 1.2 Provide Internal Force Protection 


X 


X 



FUN 2. Provide HA/DR 

X 


X 




FUN 2.1 Perform Air Connector 

X 

X 

X 

X 



FUN 2.2 Perform Surface Connector 

X 

X 

X 

X 



FUN 2.3 Perform Forward Logistics 

X 

X 

X 

X 



FUN 3. Provide Command and Command 

X 


X 


X 


FUN 3.1 Perform Resupply Functions 

X 


X 




FUN 3.2 Perform Sea Connector 

X 


X 




FUN 4. Provide Infrastructure Repair 







EXFO. Perform Country of Orange 



X 



X 

EXFl. Provide Internal Security 


X 




X 

EXF 2. Receive Aid 



X 



X 

EXF 3. Perform Hostile Group Functions 


X 




X 


5. Physical Architecture 

The physical architecture’s purpose is to identify all the physical components that 
make up the system. ICoMM also identifies the components of the external system to be 
included in the physical architecture. The purpose of both the system and external system 
components are to meet the fundamental objective of the mission, which is to provide 
regional security. 

Figure 49 shows the components of the system that performs the functions and the 
relationships of the components to each other. There are four major components in the 
system and three in the external system. ICoMM identifies the point of interaction 
between the two systems. The point of interaction is important because it is where the 
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two systems come in contact. For an observable system, the interaction between two 
systems can be observed and data can be collected. However, for a NOS, the interaction 
is not observable and no data is available. For example, the flow of interaction between 
the components of the system can be observed and the forecasted output in sync with the 
actual output. However, the outcome at the point of interaction between the system and 
the external system is less predictable. The system may deliver enough aid with no delay, 
but the reaction of the people may not be as forecasted. 


Figure 49. Physical Architecture and the Point of Interaction 



The physical architecture also has a physical hierarchy that describes the 
hierarchy of the components. The MEU assigned to the HA/DR mission includes various 
platforms to perform the required functions. The MEU includes three different 
amphibious warships serving as sea connectors; LHD, LPD, and the LSD. There is one of 
each class on the amphibious ships. Each of the ships also either carries air connectors, 
surface connectors, or both. The air connectors include a MH53 transport helicopter, a 
SH60 medium utility helicopter, and a MV-22 tilt-rotor transport. The purpose of the air 
connectors is to deliver aid to the FLSS that are remote and far away from access to the 
sea. The surface connectors include LCAC and ECU. The purpose of the surface 
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connector is to deliver aid to the FLS within proximity of the sea. Figure 50 graphically 
outlines the distribution of vehicles among the sea connectors. 


Figure 50. Distribution of Air and Surface Co nn ectors among the Amphibious 
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ICoMM identifies the external physical architecture as the composition of the 
people of COO, GOO, and hostile forces. As seen in Figure 51, both the GOO and the 
hostile forces converge on the people of Orange. The system also interacts with the 
people. The convergence to one component has a strong indication that this is the center 
of gravity of the operation. Conceptual planning of the center of gravity and 
understanding how it impacts the overall mission is an important aspect of military 
operations (Department of the Army 2014). The military center of gravity is defined by 
JP 5-0 as “a source of power that provides moral or physical strength, freedom of action, 
or will to act” (Department of Defense 2011, III-22). Identification of the military center 
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of gravity is important in this scenario because it provides better insight into the selection 
of the point of interaction. The identification of the military center of gravity also 
supports the idea that the hostile forces conduct its operations to influence the population 
to turn against the GOO. 


Figure 51. Components of the External System 



6. Allocated Architecture 

The allocated architecture provides the overall picture of the complete system. As 
previously mentioned, the external system is also included to show the interaction with 
the system. The functional and physical architectures previously discussed are the basis 
for the building of the allocated architecture. The functions identified on the functional 
hierarchy are linked to the components in the physical architecture. 

The traceability provided by the allocated architecture is shown on an IDEFO 
model. The IDFEO model uses the functional and physical decompositions to assign to 
the components to the functions. The link is made at every level. The IDEFO model 
describes not only the link between the component and the function but also the inputs 
and outputs of the model, as well as the controls the functions will be performing. The 
IDEFO model has four main components: inputs, control, outputs, and mechanisms to 
describe system. Figure 52 shows the highest-level IDEFO diagram supporting the 
fundamental objective of providing regional security. As seen in the functional hierarchy, 
five sub-level functions must be accomplished to meet the fundamental objective. 
Function 4, provide infrastructure repair, is not included in this research because it is 
outside of the scope of the military’s HA/DR mission. All the other functions are part of 
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the HA/DR mission to include the external function. The mechanism or the component 
that executes the functions one through three is the HA/DR mission or also known as the 
HA/DR mission unit. The external system, EXF.O perform COO functions, also has the 
HA/DR mission that provides support to the function. However, the primary component 
to EXF.O is the GOO. All the components of the system are controlled by the disaster 
relief-operating guide from the DOD and at the request of the COO. This is scope of the 
HA/DR mission the MEU will be executing. The following sections discuss each of the 
IDEFO components in greater detail. 
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The provide security section has two level 2 functions. Figure 53 shows that two 
functions are to provide security for the distribution of aid and internal protection. The 
functions are executed by the components of the overall HA/DR mission and by both the 
surface connector and air connector. These components perform both security and 
internal FP throughout the HA/DR mission. Both security and internal FP functions are 
performed because the co nn ectors carry FP personnel during the execution of the 
missions. Once they reach their destinations of either FLS or FLSS, the personnel of the 
connectors provide security during the distribution of aid in conjunction with the country 
of Orange security forces (COSF). The control portion of the provide security IDEFO is 
following the disaster relief guide, which provides guidance during the execution of the 
HA/ DR mission. ICoMM uses the control of the IDEFO as providing the context by 
defining the scope and boundary of their mission. Ultimately, the C&C element oversees 
the functions of security and FP. Any changes in their state are reported to the sea base to 
measure progress. The input for FUN. 1.1 is an unsecured area and the output is a secured 
area. The input for FUN. 1.2 is the state of security during the operation and the output is 
that FP is maintained. It is also to note that the output of FP also provides an input for 
FUN.I.l. It is because the level of FP has an effect on the security during the distribution 
of aid. Should the level of FP be at a level where the co nn ectors could not protect it from 
the enemy, then the mission would have to be altered to meet the requirement to provide 
security. 
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Figure 53. IDEFO Diagram of Provide Security 



7. Provide HA/DR 

The provide HA/DR function has three level 2 functions. The functions of 
perform air co nn ector missions, perform surface connector missions and to perform 
forward logistics are previously identified. The functions are all controlled by the disaster 
relief operating guide. However, the C&C of the mission provide context to only two of 
the functions as a mean of control. There are also only one input to each of the functions, 
the aid and supplies of the mission. Both of the co nn ectors receive aid supplies from the 
sea base and perform their functions to deliver the aid supplies to the FLS and FLSS. The 
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aid delivered by the connectors is the inputs to perform forward logistics and the output is 
the distribution of the aid supplies to the local population. The mechanisms assigned to 
perform the air connector functions are the MH 53, MV22 and the SH60 aircrafts. They 
are responsible for carrying the aid supplies to the FLSS. The mechanisms executing the 
surface connector functions are the LCAC and the LCU. The surface connectors deliver 
aid to the FLS. The actual FLS and the FLSS performs the functions of the forward 
logistics to ensure the flow of aid supplies from the connectors are distributed to the local 
population. Figure 54 shows the IDEFO model that traces the ICOM. 


Figure 54. IDEFO Diagram for Provide HA/DR 
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a. Provide Command and Control 

Figure 55 shows the IDEFO model for the C&C function. There are two level 2 
functions that support the C&C function, perform resupply functions as the sea base and 
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perform sea connector function. The LHD, the LPD, and the LSD amphibious ships 
perform both functions. Both inputs are the resupply from resupply ships that are for both 
internal supply needs and to distribute to the COO. 


Figure 55. IDEFO Diagram for Provide Command and Control 
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b. Perform Country of Orange Functions 

ICoMM also investigated the IDEFO model of the external system as we did of 
the system. The IDEFO model for the external system is shown in Figure 56. An IDEFO 
model must also be made for the external system to understand its functions and the 
components that will execute the external system functions. The external system’s overall 
function of performing COO functions has three sub-level functions: provide internal 
security for the GOO, receive aid, and perform hostile group functions. The functions 
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were described in detail previously in section B1 of this chapter. The following sections 
discuss the allocation of the sub-level functions to the components in greater detail. 


Figure 56. IDEFO Diagram of Perform Country of Orange Functions 



c. Provide Internal Security 

The first external system function is to provide internal security. The GOO 
executes this function. Figure 57 shows the controls for this function are the UN and U.S. 
negotiations to assist the COO and the internal laws of the country. The UN and U.S. 
organizations establish the scope and boundary of the actions of the HA/DR mission unit, 
as well as the expectation of the GOO, while the law governing the country limits the 
actions of its internal forces. The inputs are the actions of the HA/DR mission of 
conducting relief and providing a secure area. The output of this function is the state of 
the country. The state of the country may be on pace to a quick recovery or recovery may 
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be delayed due to an increase of hostile activities. The state of the country is an indicator 
measured to provide information to the stakeholders to refine and execute plans based on 
the state of the country. 


Figure 57. IDEFO Diagram for Provide Internal Security (GOO) Functions 
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d. Receive Aid 

The following external system function is to receive aid, as seen in Figure 58. As 
simple as it may sound, it is important to maintain a good measure of the amount of aid 
flowing into the FLS and the FLSS by the HA/DR mission unit. Therefore, the inputs into 
this function are the deliver mechanisms, the disaster area, and the state of both the 
security and overall country. The output is the aid supplies distributed to the people. The 
component that receives the aid is the local population. A secure area and the distribution 
of supplies control the function. 
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Figure 58. IDEFO Diagram for Receive Aid 



8. Perform Hostile Group Functions 

As previously mentioned, the hostile forces are also components that influence the 
HA/DR mission. Figure 59 shows perform hostile functions conducted by the hostile 
forces within the COO. It is controlled by the distribution of aid supplies by the HA/DR 
mission units. The hostile group forces must act if the amount of distribution increases. If 
the amount of distribution decreases, then the actions of the group may have had success 
in their efforts. The inputs are the delivery of aid from both air and sea connectors. It also 
includes whether disaster relief was conducted. Performing hostile group acts on the 
inputs produces increases anti-government sentiments. This action must be monitored 
due to its effect of reaching the fundamental objective of providing regional security. 
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Figure 59. IDEFO Model for Perform Hostile Group Functions 
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E. ESTABLISHING THE VALUE OF THE ALLOCATED FUNCTIONS 

ICoMM equates the top-level function as the “fundamental objective”. The 
fundamental objective is the overall strategic mission to provide regional security. 
“Means objectives” or sub-level objectives also support the listed functions. The means 
objectives show the preferences regarding the values intended by the stakeholders 
(Parnell, Driscoll, and Henderson 2011). The following values are the means objectives 
that are the quantitative method to evaluate the system performance and identify 
progression of the system toward the achievement the fundamental objective. The 
structure shown in Table 4 is the basis for measures of effectiveness and measure of 
performance (MOP) in military operational assessment process. Tables 5 and 6 show the 
value hierarchy for the system and the external system. The table lists the top-level 
function. As previously mentioned, the top-level function is also the fundamental 
objective of the HA/DR mission. The two rows below are the level 2 and level 3 

functions. The following rows alternate between means objectives and the measures. The 
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means objective show whether the values should be maximized or minimized. The 
measures directly below the means objectives show the measures that must be taken to 
show status of the mission. Table 5 shows means objectives and the measures for the 
system. It is listed under the systems functions. Each colu mn represents the direct support 
of objectives and measures to the functions above. 


Table 5. System Means Objectives and its Measures 


FUN O. Provide Regional Security 

FUN 1. Provide Security 

FUNtProvideHA/DR 

FUN 3. Provide Command and Control 

FUN 1.1 Provide security for distribution 

FUN 1.2 Provide Internal Force Protection 

FUN 2.1 Perform Air Connector 

FUN 2,2 Perform Surface Connector 

FUN 2,3 Perform Forward Logistics 

FUN 3,1 Perform Resupply Functions 

FUN 3.2 Perform Sea Connector 

FUN 1,1,1, MaK number of troops 

FUN 1.2,1, Max number of troops 

FUN 2.1,1, Max number of air frames 

PUN 2,2,1, Max number of surface vehicles 

FUN 2,3,1, Max amount of aid flow 

PUN 3,1,1, Max amount of resupply 

FUN 3.2,1, Max command and control 

Number of troops by specialty 

Number of troops by specialty 

Number of different aircrafts |type| 

Number of different surface crafts |type| 

AmoundofaidintoPLS8iPLS5|lbs/type| 

Amount of resupply |lbs/type| 

No loss of contact with deployed element 

Fun 1,1,2, Max number of equipment 

FUN 1,2,2, Max number of equipment 

FUN 2,1,2, Max number of aid flow 

FUN 2,2,2, Max number of aid flow 

FUN 2,3,2, Max amount of storage 

FUN 3,1,2, Max amount of storage 

FUN3,2,2, Max contact with Govt of Orange 

Number of equipment by type 

Number equipment by type 

Amount of aid delivered per day |lbs| 

Amount of aid delivered per day |lbs| 

Amount of aid stored |lbs/type| 

Amount of stored |lbs/type| 

Number of contact with GOO 


Mill Mai Paiload 

PUN 2,2.3. Max Payload 

FUN 2,3.3. Max distribution 


Amount of payload |lbs| 

Amount of payload |lbs| 

Amount of aid distributed |lbs/type| 

FUN 2,1.4, Min travel time 

PUN 2,2,4, Min travel time 



Travel time |kph| 

Travel time |mph| 


FUN 2,1,5, Min fuel usage 

PUN 2,2,5,Min fuel usage 

Amount offuel used (gal/hr| 

Amount offuel used |gal/hr| 

FUN 2,1,6, Min load time 

FUN 2,2,6, Min load time 

Time to load aircraft |min| 

Time to load surface craft |min| 

FUN 2,1,7, Min unload time 

FUN 2,2,7.Min unload time 

Time to unload aircraft |min| 

Time to unload surface craft |min| 

FUN 2,1,8, Max operating time 

FUN 2,2,8, Max operating time 

Time to operate aircraft |flthrs| 

Time to operate surface craft (flthrsl 

FUN 2,1,9, Max number of trips to FLSS 

PUN 2,2,9, Max number of trips to FLS 

Number of trips 

Number of trips 

Q Functions 

D Value Measures 


Table 6 shows the means objectives and the measures for the external system. The 
functions for the COO support primarily the requirement of receiving aid, as seen in the 
requirements hierarchy. In the functional hierarchy, the function of receiving aid supports 
the higher function of performing the function of the COO along with providing internal 
security and performing hostile group functions. An example can be seen in Figure 42. 
The means objectives and the measures support the functions of the three level 3 
functions, which support the functions of the COO. 
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Table 6. External Systems Means Objectives and Measures 


FUN 0. Provide Regional Security 


EXF 0. Perform Country of Orange 

EXF 1. Provide Internal Security 

EXF 2. Receive Aid 

EXF 3. Perform Hostile Group Functions 

EXF 1.1. Max Security forces 

EXF 2.1. Max Aid received 

EXF 3.1.Max number of anti-govt forces 

Number of security force troops 

Amount of aid (lbs / type) 

Number of anti-govt forces 

EXF 1.2. Max Distribution of COSF to FLS &FLSS 

EXF 2.2. Max aid distributed to population 

EXF 3.2. Max attack on govt facilities 

Number of security forces at FLS & FLSS 

Amount distributed (lbs / type) 

Number of attacks 

EXF 1.3. Max interaction with local poplulation 

EXF 2.3. Min distance poulation travel 

EXF 3.3. Max prevention of aid to population 

Number of engagements with population 

Distance traveled to receive aid (miles) 

Number of attacks 

EXF 1.4. Max interaction with hostile forces 

EXF 2.4 Max contact with HA/DR unit 

EXF 3.4. Max interaction with local population 

Number of engagements with hostile forces 

Number of contacts with HA/DR unit 

Number of contact with local population 

EXF 1.5 Min casulaties 


EXF 3.5. Min attack on population 

Number of casualties 


Number of attacks 



EXF 3.6. Min interaction with Govt Forces 



Number of engagements with GOO 



EXF 3.7. Min casualties 



Number of casualites 


I I Functions 
□ Value Measures 


Figure 60 is a crosswalk of the measures to functions to the objectives, and 
ultimately, to the fundamental objective. The objectives are lined up below the functions 
it supports. The arrows depict the different functions that objectives may have an effect 
on other objectives. For example, objective 2.1.3 maximizes the amount of payload by 
aircraft, which directly supports the perform air connection function that has an effect on 
the function of performing forward logistics. The inability of the air connectors to deliver 
maximum payload of aid to the forward logistics sites will hinder the forward logistics 
functions and not obtain the means objectives of maximizing the amount of storage and 
distribution of good to the local population. It also affects the external system and its 
function of receiving aid. The lack of aid delivered to the population of Orange could 
potentially assist hostile groups, and ultimately, have an inverse effect on the 
fundamental objective of providing regional security. It is important to identify 
adversarial functions and crosswalk the measures that have the possibility of hindering 
the success of the operation. 
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Figure 60. Crosswalk of the Means Objectives to the Functions 



SMEs are solicited to provide their value of the different measures after 
performing the cross walk between the objectives and functions. The inputs from the 
SMEs demonstrate the values they feel are important to the mission. The result of this 
process will capture the most important functions and objectives for the system (Parnell, 
Driscoll, and Henderson 2011). The measures are also weighted to show the potential 
impact the function will have on the overall mission. The DM is the commander of the 
mission and relies on SMEs to provide weights to the best of their knowledge. 

Table 7 is an example of the solicitation taken from the SMEs of the troops 
dedicated for FP. The number of troops dedicated FP purposes is 759. A third of the 
2,300 total troops for the mission are dedicated to FP. The stakeholder is provided with a 
degradation of troops in 10% increments from the maximum for a protection number of 
759. The stakeholder is asked to rate the values from 0 to 100. The numbers do not have 
to be in increments of 10. The table shows that there is a large drop in value when the 
number of troops drops from 380 to 304. The number of troops at 380 is 50% from the 
maximum force and the stakeholder indicates that the force may not be able to operate 
below 380. 
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Table 7. Example of Troops for Force Protection Value Solicitation from 

Stakeholders 


Troops for Force Protection 

Value 

759 

100 

683 

95 

607 

90 

531 

87 

455 

76 

380 

70 

304 

50 

228 

30 

152 

20 

76 

0 


The information Table 7 can also be depicted in a graphical manner. Figure 61 
shows a concave graph describing a decrease from an optimal number of troops to the 
least desirable number. All the value measure graphs are monotonically increasing or 
decreasing. The importance of the graph is that a DM or any other stakeholders can 
quickly assess the situation and make decisions based on the predetermined points of 
decision. These are identified on the inflection points circled on the graph. The first 
inflection point is at value 87 when the mission has taken a loss of 30 percent for the 
troops for the FP measure. The second inflection point is at value 70 when there is a 50% 
loss of troops. This number would be a warning sign to the commander to either choose a 
different course of action or begin requesting replacements. The number of troop loss is 
not only for contact loss but also due to sickness or other administrative issues. 
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Figure 61. Value Measure Number of Troops for Force Protection 


Troops for FP 



Looking back at the objectives to functions crosswalk, ICoMM identified that 
objective 1.2.1, maximize number of troops for FP, also have indirect effects on functions 
perform air co nn ector and perform surface connector. The decrease of the number of 
troops for force protection has the potential to inhibit the two-connector functions. The 
cross walk is shown in Figure 62. 


Figure 62. Maximize Number of Troops for Force Protection Objective 

Crosswalk 
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After tracing the potential impact of the decrease of the number of troops for FP 
to perform air connector, we will take a look at one of the air connector objectives that 
may potentially affect it. The objective is to maximize the number of aircraft that will be 
involved in the HA/DR mission. A total of 24 aircrafts will be participating in the 
mission. The number of aircraft that can be flown in the mission is also dependent on the 
amount of FP troops available to provide security. The reduction of FP troops also means 
a reduction in participating aircrafts. The decrease in the value is based on each aircraft 
loss. The inflection point is at value 8.4 with the loss of four aircrafts. The loss of an 
aircraft could be due to normal maintenance or loss during operation. Anything below the 
loss of four aircrafts will not be acceptable to the commander, as shown in Figure 63. 

Figure 63. Value Measure of Number of Aircrafts for HA/DR Mission 

Number of Aircrafts 



Once all the value measures are identified and graphed, global weights are 
assigned to the measures. The global weights enable the SMEs to identify the objectives 
they feel will have the most impact during the operation. While all the measures are 
tracked, the ones with greater weights receive greater emphasis. Table 8 shows the 
functions, objective, measure, the swing weights, and the global weights. The swing 
weights were solicited again from the SMEs to rate all the measures. The global weight 
measures also show the importance of the measure. 
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Table 8. Ordering of the Value and the Impact of the Functions 


FUNCTION 

OBEJECTIVE 

MEASURE 

SWING 

GLOBAL 

NORM SCORE 

FUN 1. Provide Security 

FUN 1.1 Provide security for distribution 

FUN 1.1.1. Max number of troops 

Number of troops by specialty 

64 

0.0198 

1.39 


FUN 1.1.2. Max number of equipment 

Number of equipment by type 

63 

0.0195 


FUN 1.2 Provide Internal Force Protection 

FUN 1.2.1. Max number of troops 

Number of troops by specialty 

62 

0.0192 



FUN 1.2.2. Max number of equipment 

Number equipment by type 

61 

0.0189 


FUN 2. Provide HA/DR 

FUN 2.1 Perform Air Connector 

FUN 2.1.1. Max number of air frames 

Number of different aircrafts (type) 

100 

0.0309 

2.03 


FUN 2.1.2. Max number of aid flow 

Amount of aid delivered per day (lbs) 

95 

0.0294 



FUN 2.1.3. Max Payload 

Amount of payload (lbs) 

93 

0.0288 



FUN 2.1.4. Min travel time 

Travel time (kph) 

85 

0.0263 



FUN 2.1.5. Min fuel usage 

Amount of fuel used (gal / hr) 

90 

0.0278 



FUN 2.1.6. Min load time 

Time to load aircraft (min) 

87 

0.0269 



FUN 2.1.7. Min unload time 

Time to unload aircraft (min) 

86 

0.0266 



FUN 2.1.8. Max operating time 

Time to operate aircraft (fit hrs) 

89 

0.0275 



FUN 2.1.9. Max number of trips to FLSS 

Number of trips 

97 

0.0300 


FUN 2.2 Perform Surface Connector 

FUN 2.2.1. Max number of surface vehicles 

Number of different surface crafts (type) 

84 

0.0260 

1.79 


FUN 2.2.2. Max number of aid flow 

Amount of aid delivered per day (lbs) 

99 

0.0306 



FUN 2.2.3. Max Payload 

Amount of payload (lbs) 

81 

0.0251 



FUN 2.2.4. Min travel time 

Travel time (mph) 

70 

0.0217 



FUN 2.2.5.Min fuel usage 

Amount of fuel used (gal / hr) 

74 

0.0229 



FUN 2.2.6. Min load time 

Time to load surface craft (min) 

73 

0.0226 



FUN 2.2.7.Min unload time 

Time to unload surface craft (min) 

71 

0.0220 



FUN 2.2.8. Max operating time 

Time to operate surface craft (fit hrs) 

75 

0.0232 



FUN 2.2.9. Max number of trips to FLS 

Number of trips 

83 

0.0257 


FUN 2.3 Perform Forward Logistics 

FUN 2.3.1. Max amount of aid flow 

Amound of aid into FLS &FLSS (Ibs/type) 

98 

0.0303 

1.74 


FUN 2.3.2. Max amount of storage 

Amount of aid stored (Ibs/type) 

69 

0.0213 



FUN 2.3.3. Max distribution 

Amount of aid distributed (Ibs/type) 

68 

0.0210 


FUN 3. Provide Command and Control 

FUN 3.1 Perform Resupply Functions 

FUN 3.1.1. Max amount of resupply 

Amount of resupply (Ibs/type) 

67 

0.0207 

1.61 


FUN 3.1.2. Max amount of storage 

Amount of stored (ibs/type) 

66 

0.0204 


FUN 3.2 Perform Sea Connector 

FUN 3.2.1. Max command and control 

No loss of contact with deployed element 

92 

0.0285 



FUN 3.2.2. Max contact with Govt of Orange 

Number of contact with GOO 

65 

0.0201 


EXF 0. Perform Country of Orange 

EXF 1. Provide Internal Security 

EXF 1.1. Max Security forces 

Number of security force troops 

55 

0.0170 

1.20 


EXF 1.2. Max Distribution of COSF to FLS &FLSS 

Number of security forces at FLS & FLSS 

54 

0.0167 



EXF 1.3. Max interaction with local poplulation 

Number of engagements with population 

53 

0.0164 



EXF 1.4. Max interaction with hostile forces 

Number of engagements with hostile forces 

52 

0.0161 



EXF 1.5 Min casulaties 

Number of casualties 

56 

0.0173 


EXF 2. Receive Aid 

EXF 2.1. Max Aid received 

Amount of aid (lbs / type) 

96 

0.0297 

1.66 


EXF 2.2. Max aid distributed to population 

Amount distributed (lbs / type) 

92 

0.0285 



EXF 2.3. Min distance poulation travel 

Distance traveled to receive aid (miles) 

50 

0.0155 



EXF 2.4 Max contact with HA/DR unit 

Number of contacts with HA/DR unit 

60 

0.0186 


EXF 3. Perform Hostile Group Functions 

EXF 3.1.Max number of anti-govt forces 

Number of anti-govt forces 

49 

0.0152 

1.13 


EXF 3.2. Max attack on govt facilities 

Number of attacks 

59 

0.0183 



EXF 3.3. Max prevention of aid to population 

Number of attacks 

58 

0.0179 



EXF 3.4. Max interaction with local population 

Number of contact with local population 

40 

0.0124 



EXF 3.5. Min attack on population 

Number of attacks 

57 

0.0176 



EXF 3.6. Min interaction with Govt Forces 

Number of engagements with GOO 

46 

0.0142 



EXF 3.7. Min casualties 

Number of casualites 

48 

0.0149 




TOTAL= 

'^ 3232 

1.0000 



F. SUMMARY 

This chapter presented a proof of concept of the application of ICoMM by 
applying SE and SA processes to build a conceptual model of a HA/DR scenario. The 
incorporation of SMEs values and improved structure demonstrated that ICoMM can 
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facilitate face and traces validation techniques. It also identified methods for supporting 
the operational validation of a NOS by model exploration. The inclusion of SE methods 
in the MDP facilitated the identification of requirements, functional, and physical 
analysis. The analysis was conducted simultaneously for the system and the external 
system to demonstrate potential interaction between the two systems. The operational 
behaviors of the interactions are not directly observable. It is important to note that the 
functions of both systems affect each other in some way and the SMEs values of these 
functions must be documented during the building of the CoM. Therefore, it is important 
that a clearly traceable CoM is created prior to the execution of a simulation to minimize 
the uncertainty produced by the interaction of the two systems. ICoMM ensures that this 
information is available during the model exploration of a NOS. 
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V. CONCLUSION 


A. SUMMARY 

This research demonstrated the importance of an improved structure of the CoM 
for validation to gain greater trust by the DMs. A secondary result was gained by a 
greater understanding of the application of SE and SA processes to improve the structure 
of CoMs. ICoMM addresses the difficulty of operationally validating systems classified 
as non-observable that can be improved by designing the CoM early in the MPD with 
facilitated early SME involvement and a structure that logically connects the 
measurements to the fundamental objective. 

The most recent research into this domain lacked structure to demonstrate clear 
traceability from the measures of performance and effectiveness to the fundamental 
objective. This research demonstrated that the application of SE processes to decompose 
systems and build models of the systems by applying SA techniques improves the 
traceability of the model. Traceability of the model is critical in supporting validation. 
Face validation techniques are normally applied when validating a NOS, as actual data 
may not exist to apply mathematical or simulation solutions. ICoMM demonstrated that 
the operational validation of models of a NOS could be improved with greater 
involvement of stakeholders by soliciting their values. Ultimately, the stakeholders 
validate the models of systems. The DOD defines validation as the following: 

The process of determining the degree to which a model, simulation, or 
federation of models and simulations, and their associated data are 
accurate representations of the real world from the perspective of the 
intended use(s). (Department of Defense 2009, 9) 

Scenarios of potential future conflicts had to be created to gain an understanding 
of the unknown environment. This research chose to continue to model the HA/DR 
scenario of EWIO previously studied by NFS SE students and Georgia Tech to apply 
ICoMM for comparison. The scenario demonstrated that the non-observable aspect of the 
system was the interaction with the external system. Specification of the system was well 
known. However, the effects of the systems functions interacting with the external system 
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were not known and non-observable. Thus, operational validation of the system was not 
feasible and the only method to support operational validation was through model 
exploration of the CoM. 

B. CONCLUSIONS 

This research clearly demonstrated the utility of ICoMM in building well- 
structured CoMs by using SE and SA processes. Face and traces validation methods used 
for conceptual models are also improved using the SE and SA processes using ICoMM. 
This demonstration can be applied to future military operational assessments process. The 
methodology supports the following characteristics: 

• Traceability—^provides the stakeholders the ability to trace from MOPs 
and measures of effectiveness (MOEs) to fundamental objectives. 

• Validation—supports face validation techniques traditionally used models 
and simulations of military operation by involving stakeholders early in 
the architecting process. 

• Iterative—^provides a method that can be repeated for different operational 
situations. 

Figure 64 presents an overview of the dissertation of applying ICoMM to model 
development. Starting from the top-left comer, this research integrated SE and SA 
processes into Sargent’s (2001) Evolved MDP. The SE and SA processes decomposed 
the system to begin building the CoM in the top-right comer. The bottom-right comer 
shows a refined stmcture of the CoM that identifies the measurements and the supported 
objectives. Finally, the bottom-left comer shows the table of functions with SME inputs 
to provide quantifiable measurements to the NOS. 


no 



Figure 64. Dissertation Overview 



Several things were revealed as a result of this research. There are many MDPs, 
but this research has not found one that demonstrates clearly how to transfer the systems 
definition to the development of the CoM. Many mention systems definition as a part of a 
MDP, but do not clearly outline the methodology. It is understood that most models built 
are of systems. Therefore, an understanding of SE processes if vital to building a model 
that represents the system. 

The next revelation was that SMEs must be actively involved in building the 
model. The SMEs evaluate the model for correctness in representing the system in as real 
world environment and present their findings to DMs, which influences their decisions. 

C. FUTURE WORK 

This research was a continuation of a recent study of the modeling of NOSs for 
simulation. There remain a large number of potential extensions of this work. SE 
methodology was used in this research to decompose the system and to build an 
architecture that would improve the model of a NOS and the traceability for validation of 
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the model. The logical following step would be to find a simulation model that would use 
the steps outlined in this research to model the system and allow traceability from the 
measurements to the fundamental objectives. There has been research in conceptual 
models for discrete event simulations (DBS). ICoMM may potentially be applied to build 
the initial state of the system for DBS. 

Another extension of this research would be to develop a system of systems 
(SOS). This research considers the interaction of the system and an external system but 
not the subsystems. SOS has five characteristics: operational independence, managerial 
independence, geographically distributed, emergent behavior, and evolutionary 
development (Rainey and Tolk 2014). These characteristics were not considered in this 
research. There would definitely be new challenges to trying to observe different systems 
performing with the five characteristics. The appearance of emergent behavior within the 
SOS and accounting for the unobservable behavior with the interaction of the external 
system would be very difficult. 

Finally, applying this method in a real world environment would be the most 
desirable. This research was conducted with the military planners and assessment officers 
in mind. Any application that has the potential to assist these staff officers in conducting 
their daily business would be greatly beneficial to the U.S. military. 
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APPENDIX A. VITECH CORE OUTPUTS 


OUTPUT PART 1 - Functions List 

EXF.O Perform Country of Orange Functions 
EXF.l Provides Internal Security (GOO) 

EXE.2 Receive Aid 

EXE.3 Perform Hostile Group Functions 
FUN.O Provide Regional Stability 
FUN.l Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 

FUN. 1.2 Provide Internal Force Protection 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Connector 

FUN.2.2 Perform Surface Connector 

FUN.2.3 Perform Forward Fogistics 

FUN.3 Provide Command and Control 

FUN.3.1 Performs Resupply functions (Sea Base) 

FUN.3.2 Perform Sea Connector 
FUN.4 Provide Infrastructure Repair 

Part II - Behavior Model _ 

EXF.O Perform Country of Orange Functions 

Allocated To: 

EXS.l Government of Orange 

Table 1 EXF.O Perform Country of Orange Functions Interfacing Items 


Interfacing Items 

Source / Destination 

Disaster Relief Conducted 

Input To: 

EXF.O Perform Country of Orange Functions 

Output From: 

FUN.2 Provide HA/DR 

Secure Area 

Input To: 

EXF.O Perform Country of Orange Functions 

Output From: 

EXF.l Provides Internal Security (GOO) 

FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 

State of the Country 

Input To: 

EXF.l Provides Internal Security (GOO) 

FUN. 1 Provide Security 
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Table 1 EXF.O Perform Country of Orange Functions Interfacing Items 


Interfacing Items 

Source / Destination 


FUN.2 Provide HA/DR 

FUN.3 Provide Command and Control 

Output From: 

EXF.O Perform Country of Orange Funetions 


Table 1 EXF.O Perform Country of Orange Functions Interfacing Items 


eflFbd Perfam Country of Orange Rjnctions 




Univeraty Edition - For Academic Use Only 

Date: 

August 5, 2015 




Figure 1 Perform Country of Orange Functions (Enhanced FFBD) 
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idefO Perform Country of Orange Functions 
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State of Security 
State of Ihe Country 


D isaste r R eli ef C ond ucted 
Secure Area 



Secure Area 


State of tie Country 


Government of Orange 
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Date: 
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August 5, 2015 


Figure 2 Perform Country of Orange Functions (IDEFO Diagram) 


act Perform Country of Orange Functions 
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Date: 

University Edition - For Academic Use Only 

August 5, 2015 


Figure 3 Perform Country of Orange Functions (Activity Diagram) 

EXF.l Provides Internal Security (GOO) 


Allocated To: 

EXS.l Government of Orange 
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Table 2 EXF.l Provides Internal Security (GOO) Interfacing Items 


Interfacing Items 

Source / Destination 

Secure Area 

Input To: 

EXF.O Perform Country of Orange Functions 

Output From: 

EXF.l Provides Internal Security (GOO) 

FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 

State of Security 

Input To: 

EXF.l Provides Internal Security (GOO) 

FUN.3 Provide Command and Control 

Output From: 

FUN. 1 Provide Security 

State of the Country 

Input To: 

EXF.l Provides Internal Security (GOO) 

FUN. 1 Provide Security 

FUN.2 Provide HA/DR 

FUN.3 Provide Command and Control 

Output From: 

EXF.O Perform Country of Orange Functions 



Figure 4 Provides Internal Security (GOO) (Enhanced FFBD) 
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Figure 5 Provides Internal Security (GOO) (IDEFO Diagram) 



Figure 6 Provides Internal Security (GOO) (Activity Diagram) 


EXF.2 Receive Aid 

Allocated To: 

EXS.1.2 People Of Orange 

EXF.3 Perform Hostile Group Functions 

Allocated To: 

EXS.2 Hostile Forees 


Table 3 EXF.3 Perform Hostile Group Functions Interfacing Items 


Interfacing Items 

Source / Destination 

Attack Convoy 

Triggers Function(s): 

EXF.3 Perform Hostile Group Functions 


117 













































FUN.O Provide Regional Stability 

Allocated To: 

0 HA/FA Mission 



Figure 7 Provide Regional Stability (Enhanced FFBD) 
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idefO Provide Regional Stability J 


Disaster Relief Ope rating Gride 
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Figure 8 Provide Regional Stability (IDEFO Diagram) 
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Figure 9 Provide Regional Stability (Activity Diagram) 


FUN.l Provide Security 

Allocated To: 

0 HA/FA Mission 

Specified By Requirements: 

REQ.2.1 Provide Security (Sea) 

REQ.3.1 Provide Security (Air) 

REQ.4.2 Provide Security (Surface) 
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Table 4 FUN.l Provide Security Interfacing Items 


Interfacing Items 

Source / Destination 

Command and Control 

Triggers Funetion(s): 

FUN. 1 Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

Output From: 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 

Disaster Relief Operating Guide 

Triggers Funetion(s): 

FUN. 1 Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

FUN.2.3 Perform Forward Logisties 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 

Seeure Area 

Input To: 

EXF.O Perform Country of Orange Funetions 

Output From: 

EXF.l Provides Internal Seeurity (GOO) 

FUN. 1 Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

State of Seeurity 

Input To: 

EXF.l Provides Internal Seeurity (GOO) 

FUN.3 Provide Command and Control 

Output From: 

FUN. 1 Provide Seeurity 

State of the Country 

Input To: 

EXF.l Provides Internal Seeurity (GOO) 

FUN. 1 Provide Seeurity 

FUN.2 Provide HA/DR 

FUN.3 Provide Command and Control 

Output From: 

EXF.O Perform Country of Orange Funetions 

Unseeure Area 

Input To: 

FUN. I Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 
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idefO Provide Security J 


Unsecure Area ■ 


State of Ihe Country 


Command and Cc^e^ter Relief Operating Guide 


FUN. 1.1 
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Figure 11 Provide Security (IDEFO Diagram) 
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Figure 12 Provide Security (Activity Diagram) 


FUN. 1.1 Provide Security for distribution of Aid 

Allocated To: 

0 HA/FA Mission 

Table 5 FUN.1.1 Provide Security for distribution of Aid Interfacing Items 


Interfacing Items 

Source / Destination 

Command and Control 

Triggers Funetion(s): 

FUN. 1 Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

Output From: 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 

Disaster Relief Operating Guide 

Triggers Funetion(s): 

FUN. 1 Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

FUN.2.3 Perform Forward Logisties 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 
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Table 5 FUN.1.1 Provide Security for distribution of Aid Interfacing Items 


Interfacing Items 

Source / Destination 

FP Maintained 

Input To: 

FUN. 1.1 Provide Security for distribution of Aid 

Output From: 

FUN.1.2 Provide Internal Force Protection 

Secure Area 

Input To: 

EXF.O Perform Country of Orange Functions 

Output From: 

EXF.l Provides Internal Security (GOO) 

FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 

Unsecure Area 

Input To: 

FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 
FUN.1.2 Provide Internal Force Protection 


Table 6 FUN.1.2 Provide Internal Force Protection Interfacing Items 


Interfacing Items 

Source / Destination 

Command and Control 

Triggers Function(s): 

FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 
FUN.1.2 Provide Internal Force Protection 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Connector 

FUN.2.2 Perform Surface Connector 

Output From: 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Connector 

Disaster Relief Operating Guide 

Triggers Function(s): 

FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 
FUN.1.2 Provide Internal Force Protection 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Connector 

FUN.2.2 Perform Surface Connector 

FUN.2.3 Perform Forward Eogistics 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Connector 

FP Maintained 

Input To: 

FUN. 1.1 Provide Security for distribution of Aid 

Output From: 

FUN.1.2 Provide Internal Force Protection 

Unsecure Area 

Input To: 
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Table 6 FUN.1.2 Provide Internal Force Protection Interfacing Items 


Interfacing Items 

Source / Destination 


FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 
FUN.1.2 Provide Internal Force Protection 


FUN.2 Provide HA/DR 

Allocated To: 

0 HA/FA Mission 

Table 7 FUN.2 Provide HA/DR Interfacing Items 


Interfacing Items 

Source / Destination 

Command and Control 

Triggers Function(s): 

FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 
FUN.1.2 Provide Internal Force Protection 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Connector 

FUN.2.2 Perform Surface Connector 

Output From: 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Connector 

Disaster Area 

Input To: 

FUN.2 Provide HA/DR 

Disaster Relief Conducted 

Input To: 

EXF.O Perform Country of Orange Functions 

Output From: 

FUN.2 Provide HA/DR 

Disaster Relief Operating Guide 

Triggers Function(s): 

FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 
FUN.1.2 Provide Internal Force Protection 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Connector 

FUN.2.2 Perform Surface Connector 

FUN.2.3 Perform Forward Logistics 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Connector 

State of HA/DR 

Input To: 

FUN.3 Provide Command and Control 

Output From: 

FUN.2 Provide HA/DR 

State of the Country 

Input To: 

EXF.l Provides Internal Security (GOO) 
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Table 7 FUN.2 Provide HA/DR Interfacing Items 


Interfacing Items 

Source / Destination 


FUN. 1 Provide Security 

FUN.2 Provide HA/DR 

FUN.3 Provide Command and Control 

Output From: 

EXF.O Perform Country of Orange Functions 



Figure 13 Provide HA/DR (Enhanced FFBD) 
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Figure 14 Provide HA/DR (IDEFO Diagram) 
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FUN.2.1 Perform Air Connector 


Allocated To: 

COMP.2.2 SH60 
COMP.2.3 OV22 


Table 8 FUN.2.1 Perform Air Connector Interfacing Items 


Interfacing Items 

Source / Destination 

Aid/Supplies 

Input To: 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

Output From: 

FUN.3.1 Performs Resupply funetions (Sea Base) 
FUN.3.2 Perform Sea Conneetor 

Command and Control 

Triggers Funetion(s): 

FUN. 1 Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

Output From: 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 

Delivery by Air 

Input To: 

FUN.2.3 Perform Forward Logisties 

Output From: 

FUN.2.1 Perform Air Conneetor 

Disaster Relief Operating Guide 

Triggers Funetion(s): 

FUN. 1 Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

FUN.2.3 Perform Forward Logisties 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 


FUN.2.2 Perform Surface Connector 

Allocated To: 
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COMP.3.1 LCAC 
COMP.3.2 LCU 


Table 9 FUN.2.2 Perform Surface Connector Interfacing Items 


Interfacing Items 

Source / Destination 

Aid/Supplies 

Input To: 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

Output From: 

FUN.3.1 Performs Resupply funetions (Sea Base) 
FUN.3.2 Perform Sea Conneetor 

Command and Control 

Triggers Funetion(s): 

FUN. 1 Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

Output From: 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 

Delivery by Surfaee 

Input To: 

FUN.2.3 Perform Forward Logisties 

Output From: 

FUN.2.2 Perform Surfaee Conneetor 

Disaster Relief Operating Guide 

Triggers Funetion(s): 

FUN. I Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

FUN.2.3 Perform Forward Logisties 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 


FUN.2.3 Perform Forward Logistics 

Allocated To: 

COMP.4.1 FLS 
COMP.4.2 FLSS 


129 




Table 10 FUN.2.3 Perform Forward Logistics Interfacing Items 


Interfacing Items 

Source / Destination 

Delivery by Air 

Input To: 

FUN.2.3 Perform Forward Logistics 

Output From: 

FUN.2.1 Perform Air Connector 

Delivery by Surface 

Input To: 

FUN.2.3 Perform Forward Logistics 

Output From: 

FUN.2.2 Perform Surface Connector 

Disaster Relief Operating Guide 

Triggers Function(s): 

FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 

FUN. 1.2 Provide Internal Force Protection 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Connector 

FUN.2.2 Perform Surface Connector 

FUN.2.3 Perform Forward Logistics 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Connector 

Distribution of Aid/Supplies 

Output From: 

FUN.2.3 Perform Forward Logistics 


FUN.3 Provide Command and Control 

Allocated To: 

0 HA/FA Mission 


Table 11 FUN.3 Provide Command and Control Interfacing Items 


Interfacing Items 

Source / Destination 

Command and Control 

Triggers Function(s): 

FUN. 1 Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 

FUN. 1.2 Provide Internal Force Protection 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Connector 

FUN.2.2 Perform Surface Connector 

Output From: 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Connector 

Disaster Relief Operating Guide 

Triggers Function(s): 

FUN. 1 Provide Security 
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Table 11 FUN.3 Provide Command and Control Interfacing Items 


Interfacing Items 

Source / Destination 


FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

FUN.2.3 Perform Forward Logisties 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 

State of HA/DR 

Input To: 

FUN.3 Provide Command and Control 

Output From: 

FUN.2 Provide HA/DR 

State of Seeurity 

Input To: 

EXF.l Provides Internal Seeurity (GOO) 

FUN.3 Provide Command and Control 

Output From: 

FUN. 1 Provide Seeurity 

State of the Country 

Input To: 

EXF.l Provides Internal Seeurity (GOO) 

FUN. 1 Provide Seeurity 

FUN.2 Provide HA/DR 

FUN.3 Provide Command and Control 

Output From: 

EXF.O Perform Country of Orange Funetions 



Figure 16 Provide Command and Control (Enhanced FFBD) 


131 













































Figure 17 Provide Command and Control (IDEFO Diagram) 



Figure 18 Provide Command and Control (Activity Diagram) 
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FUN.3.1 Performs Resupply functions (Sea Base) 

Allocated To: 

0 HA/FA Mission 


Table 12 FUN.3.1 Performs Resupply functions (Sea Base) Interfacing Items 


Interfacing Items 

Source / Destination 

Aid from Resupply Ship 

Input To: 

FUN.3.1 Performs Resupply funetions (Sea Base) 
FUN.3.2 Perform Sea Conneetor 

Aid/Supplies 

Input To: 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

Output From: 

FUN.3.1 Performs Resupply funetions (Sea Base) 
FUN.3.2 Perform Sea Conneetor 


FUN.3.2 Perform Sea Connector 

Allocated To: 

COMP. 1.2 LHD 
COMP. 1.3 LPD 
COMP. 1.4 LSD 


Table 13 FUN.3.2 Perform Sea Connector Interfacing Items 


Interfacing Items 

Source / Destination 

Aid from Resupply Ship 

Input To: 

FUN.3.1 Performs Resupply funetions (Sea Base) 
FUN.3.2 Perform Sea Conneetor 

Aid/Supplies 

Input To: 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

Output From: 

FUN.3.1 Performs Resupply funetions (Sea Base) 
FUN.3.2 Perform Sea Conneetor 

Command and Control 

Triggers Funetion(s): 

FUN. 1 Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 
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Table 13 FUN.3.2 Perform Sea Connector Interfacing Items 


Interfacing Items 

Source / Destination 


Output From: 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 

Disaster Relief Operating Guide 

Triggers Funetion(s): 

FUN. 1 Provide Seeurity 

FUN. 1.1 Provide Seeurity for distribution of Aid 

FUN. 1.2 Provide Internal Foree Proteetion 

FUN.2 Provide HA/DR 

FUN.2.1 Perform Air Conneetor 

FUN.2.2 Perform Surfaee Conneetor 

FUN.2.3 Perform Forward Logisties 

FUN.3 Provide Command and Control 

FUN.3.2 Perform Sea Conneetor 


{tc “6 Components Part I - Components List 


0 HA/FA Mission 
COMP.l Sea Base Connector 
COMP. 1.2 LHD 
COMP. 1.3 LPD 
COMP. 1.4 LSD 
COMP.2 Air Connector 
COMP.2.1 MH53 
COMP.2.2 SH60 
COMP.2.3 OV22 
COMP.3 Surface Connector 
COMP.3.1 LCAC 
COMP.3.2 LCU 
COMP.4 Logistcal Sites 
COMP.4.1 FLS 
COMP.4.2 FLSS 
EXS.l Government of Orange 
EXS.1.2 People Of Orange 
EXS.2 Hostile Forces 


Part II - Component Definitions 
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0 HA/FA Mission 


Type: System of Systems 

Built From Lower-Level Component(s): 
COMP.l Sea Base Connector 
COMP.4 Logistcal Sites 
EXS.l Government of Orange 
EXS.2 Hostile Forces 



Figure 19 HA/FA Mission (Physical Block Diagram) 

Performs Function(s): 

FUN.O Provide Regional Stability 
FUN.l Provide Security 

FUN. 1.1 Provide Security for distribution of Aid 
FUN. 1.2 Provide Internal Force Protection 
FUN.2 Provide HA/DR 
FUN.3 Provide Command and Control 
FUN.3.1 Performs Resupply functions (Sea Base) 


COMP.l Sea Base Connector 

Description: 

The system context identifies the physical context (the environment and external systems 
your system interacts with) enabling you to specify the system boundary. 

Type: System of Systems 

Built In Higher-Level Component(s): 

0 HA/FA Mission 

Built From Lower-Level Component(s): 

COMP.2 Air Connector 
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COMP.3 Surface Connector 


pbd Sea Base Connector J 
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Figure 20 Sea Base Connector (Physical Block Diagram) 


Connected to Physical Link(s): 

Sea to Air 
Surface Connector 

COMP.1.2 LHD 

Type: System 

Performs Function(s): 

FUN.3.2 Perform Sea Connector 
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COMP.1.3 LPD 

Performs Function(s): 

FUN.3.2 Perform Sea Connector 

COMP.1.4 LSD 

Performs Function(s): 

FUN.3.2 Perform Sea Connector 

COMP.2 Air Connector 

Type: Subsystem 

Built In Higher-Level Component(s): 
COMP.l Sea Base Connector 

Connected to Physical Link(s): 

Air to FLS 
Air to FLSS 
Air to Log 
Sea to Air 

COMP.2.1 MH53 
COMP.2.2 SH60 

Performs Function(s): 

FUN.2.1 Perform Air Connector 

COMP.2.3 OV22 

Performs Function(s): 

FUN.2.1 Perform Air Connector 

COMP.3 Surface Connector 

Type: Subsystem 

Built In Higher-Level Component(s): 
COMP.l Sea Base Connector 

Connected to Physical Link(s): 

Surface Connector 
Surface to FLS 
Surface to FLSS 
Surface to Log 

COMP.3.1 LCAC 

Performs Function(s): 

FUN.2.2 Perform Surface Connector 
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COMP.3.2 LCU 

Performs Function(s): 

FUN.2.2 Perform Surface Connector 

COMP.4 Logistcal Sites 

Built In Higher-Level Component(s): 

0 HA/FA Mission 

Connected to Physical Link(s): 

Air to Log 
Log to People 
Surface to Log 

COMP.4.1 FLS 

Performs Function(s): 

FUN.2.3 Perform Forward Logistics 

COMP.4.2 FLSS 

Performs Function(s): 

FUN.2.3 Perform Forward Logistics 

EXS.l Government of Orange 

Type: External System 

Built In Higher-Level Component(s): 

0 HA/FA Mission 

Built From Lower-Level Component(s): 
EXS.1.2 People Of Orange 
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Figure 21 Government of Orange (Physieal Bloek Diagram) 


Connected to Physical Link(s): 

Provide Internal Security 

Performs Function(s): 

EXF.O Perform Country of Orange Functions 
EXF.l Provides Internal Seeurity (GOO) 


EXS.1.2 People Of Orange 

Type: Context 

Built In Higher-Level Component(s): 
EXS.l Government of Orange 

Connected to Physical Link(s): 
FLC-POO 
FLSS-POO 
Hostile Intent 
Influence People 
Influence People of Orange 
Internal Security 
Log to People 
Provide Internal Security 

Performs Function(s): 

EXF.2 Receive Aid 

EXS.2 Hostile Forces 


Type: Context 
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Built In Higher-Level Component(s): 

0 HA/FA Mission 

Connected to Physical Link(s): 

Influence People of Orange 

Performs Function(s): 

EXF.3 Perform Hostile Group Functions 
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APPENDIX B. VEHICLE PLATFORM SPECIFICATIONS 


The following table is the list of capabilities for each of the platforms used in the 
HA/DR mission. 


Sea Base 


LHD 


LPD 


LSD 


Sea Connectors 


LCAC 


LCU 


Air Connectors 


MH-53 


SH-60 


Velocity (kts)- SeabaseOps 


40 


150 


215 


160 


Payload |U.S. tons) 


2711,69 


2535,32 


1234,59 


75 


170 


18 


17,5 


Fuel Capacity 


314160 


5000 


2277 


590 


Refuel Initiation Threshold f/o) 


30 


30 


30 


30 


30 


30 


30 


Refuel Completion Threshold {°/o| 


95 


95 


95 


100 


100 


100 


100 


100 


Refuel Rate (at sea-Gal/hr) 


252000 


252000 


252000 


60000 


Replenishment Initiation Threshold |°/o| 


Replenishment Completion Threshold (°/o) 
Replenishment Rate (at sea •U.S.Tons/hr| 
Load Time (Hr) 

Unload Time (Hr) 

Range before Refuel (Nmi) 

Fuel Consumption time (Hr) 

Operating Time Limit (Hr/Day) 


1 2 

4,5 

0,01666667 

' 0,03333333 

0,01666667 

2 

4,5 

mm 

' 0.03333333 

0,01666667 

200 

1200 

700 

950 

450 

5 

150 

4,67 

4,4 

2,8 

1 

16 

8 

8 

8 
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